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Description 

Field of Invention 

5 The invention relates to multiprocessor computer systems and in particular to facilities that aid in the development 

of computer programs for those systems. 

Background of the Invention 

10 Computer-Aided Software Engineering (CASE) software or "facilities" assist computer programmers or system 

developers in the design, development and testing of a computer program. 

Traditionally, the steps necessary to implement a computer program were performed manually. Design teams 
follow a number of discrete steps to create a useful application program from a nascent idea. 

The analysis begins by manually developing a model in which a problem can be solved by computer. Design teams 
is evaluate the needs of the prospective users and the properties that the computer system should possess to meet those 
needs. 

In the technical design phase of development, developers begin to define how the application program will be built 
on a given system. They manually determine the procedural and data elements needed and how the data and proce- 
dures will be assembled to form the software solution. At this phase the two major tasks are data-modeling and process- 
20 modeling. 

With the basic design of the program modeled, developers then begin the task of coding the program. Computer 
programs are generally written in high-level programming language such as BASIC, C, COBOL, FORTRAN or PL/I. 
The task of reducing the theoretical design of an application to working code is an arduous task that requires many 
man-hours. Experience in the programming language used to develop the program is necessary. 
2s With the code written, the design team's next problem is to debug the program for syntax errors, and then test the 

program to determine whether the application performs the desired function. Typically, the debugging and testing phase 
requires the programmer to evaluate a program at the code level. 

The programmer's development tasks become more challenging with the use of multiprocessing systems archi- 
tecture. 

30 Traditionally, there have been two basic hardware configurations employed in the design of computer systems for 

multiple users. In one configuration all of a system's processing is performed by one large "mainframe" computer Each 
user accesses that system through non -processing terminals. 

A network system is the second traditional hardware configuration. A network is comprised of a number of individual 
processing units that are interconnected to allow the sharing of data and software. There may be additional processors 
35 to maintain a group's centralized database and additional processors may be dedicated to the maintenance of the 
system's operation. The use of a network of processors each dedicated to specific aspects of a computer system is 
the essence of multiprocessing. 

The growth of the use of multiprocessing systems can be traced to the proliferation and development of powerful 
"micro" or "personal" computers (PC's). Within certain constraints, a PC can perform many of the same processing 
^o tasks that mainframe or mini computers do. However, a PC can perform these tasks with substantial savings of in- 
structions executed by the computer, measured in millions of instructions per second, "MIPS". Moreover, unlike a 
mainframe system, a PC is dedicated to a single user. An efficient multiprocessing system encourages data sharing 
and the use of dedicated PC's for as many tasks as possible. 

In multiprocessor systems, an application may be executed on more than one processor. When various parts of 
45 an application program are executed on separate processors, the application is "distributed." Distributed processing 
can be executed either in a serial sequence or in parallel. 

The simultaneous execution of a program on many processors is parallel processing. Sequential execution of a 
program across different hardware environments is serial or "cooperative" processing. 

Multiprocessing capability brings new challenges to computer system designers. Whereas in a mainframe envi- 
50 ronment all parts of the program were programmed for a single environment, in multiprocessing systems designers 
can choose the particular environment where specific aspects of a program will run. 

Although this freedom to distribute the program results in a highly efficient application, the programmers must now 
construct programs designed to execute in many hardware environments. 

The task of programming multiprocessing systems involves difficult problems of swapping data across different, 
55 and incompatible environments. For example, a file containing data stored in a PL/I format is not readable by a program 
written in a different language such as C or COBOL. A programmer must design special software to handle the com- 
munication problems inherent in multiprocessing systems. 

In addition, a programmer must code the various distributed programs in the language supported by that environ- 
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ment. For example, if the PC processors support only programs written in C language, those parts of the program must 
be in C. Whereas the other parts of the program, such as those on the mainframe, may have to be written in another 
programming language. 

Programming in a multiprocessor environment is very complex and time consuming. Staffing requirements for 
designing an application in a multiprocessor environment alone can make the task cost prohibitive. CASE facilities 
were created to alleviate some of the burden multiprocessing architecture placed on the programmer. 

Traditionally, CASE facilities allow a user to input a high-level logical design of a program which is then translated 
into code in a particular computer language. However, the CASE facilities currently available do not give the system 
developer a completely integrated system for the design, implementation and maintenance of a software application. 
The current facilities do not support the devebpment of a program in a centralized location and where translated code 
is created and distributed to various environments. The current CASE tools also do not provide a method for re-using 
parts of a previously developed application that may be usable in an application under development. The current CASE 
facilities do not provide adequate testing and debugging tools. 

One of the dilemmas in designing a CASE tool is that the output one is required to provide the user lor the planning 
phases of the project is different from the output required later on, during implementation. Early CASE tools tended to 
emphasize support for one of these two categories of activity, and scrimp on the other. 

With prior design-oriented CASE tools, the output of a designer's work with the tool was a picture. What a designer 
would end up with is documentation that could be used to actually create a system, but not the actual system itself. In 
addition, if during the implementation phase, a user discovered a reason to change any aspect of the program, the 
designer had to go back and manually identify the change and update the documentation - the documentation was 
useless unless it was compulsively updated. The actual implementation of the system, as well as any changes, were 
done using traditional methods. The only advantage of using a design-oriented CASE tool was that it produced friendly, 
complete documentation that really helped in design at the early stages. 

The second family of CASE tools were implementation-oriented. They allowed a designer to draw a diagram of 
an entire model, but not of a piece of a module. Essentially, the designer could get a picture of whatever model the 
designer was working on. When the designer unloaded the model to the mainframe repository the model replaced 
whatever model was already stored there. The actual documentation of these systems was primitive and inflexible. 

In an article entitled "An approach to the Support of Software Evolution' by I. Sommerville and R. Thomson, Com- 
puter Journal, Vol., 32, No. 5, October 1989, a system is described for supporting all stages of the software life cycle. 
Specifically, the system supports communication and documentation of the structure of a software system project as 
it develops. However, the system does not generate actual computer programs. 

Summary of the Invention 

The present invention is a CASE facility providing a method and apparatus for designing, implementing and main- 
taining software that runs in multiple hardware environments - a distribution that is transparent to the end-user. 

One aspect of the invention is a method of modeling the program structure and the data used by the program 
through an entity-relationship modeling technique. 

Another aspect is a relational database, where data is stored according to the entity-relationship model. 

Another aspect is the high-level Rules Language in which the logic of a program can be specified in a highly 
modular form, promoting ease of re -usability. 

The invention provides the capability for generating source-code for the program in a language supported by 
various hardware entities in the multiprocessing system, using the entity-relationship model and the high-level Rules 
Language modules. 

To generate the program's source-code the invention provides basic program elements to execute the program in 
a multiprocessing environment. These program components and low-level routines are combined with the Rules Lan- 
guage modules and data type entities to create the program. 

The invention further provides facilities to distribute, assemble and compile the program developed using the CASE 
facility of the present invention, as well as test and modify the program. 

Brief Description of the Drawings 

FIG. 1 is an illustration of a three-tiered computer system. 

FIG. 2 is a diagrammatic representation of the program elements according to the present invention. 
FIG. 2A is a diagrammatic representation of sample developmental workbench modules placed in a PC hardware 
environment. 

FIG. 3 is a diagrammatic representation of a sample entity- relationship according to the present invention. 
FIG. 4 is a diagrammatic representation of a sample entity decomposition according to the present invention. 
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FIGS. 5 and 6 are diagrammatic representations o1 the entity-relationship model for application programs according 
to the present invention. 

FIG. 7 is a diagrammatic representation of the Process Flow for a sample program using entity-relationship mod- 
eling techniques according to the presented invention. 

5 

Detailed Description of the Invention 

A. Hardware 

io A typical hardware configuration for a computer system using the CASE facility of the present invention is shown 

in FIG. 1. The figure describes a "three tiered" computer system, named for the three distinct types of processors 
networked: the mainframe computer 1 , as for example, an IBM 3090, a mini or supermini computer 2, as for example 
an IBM S/88 or Stratus, and a plurality of micro-computer workstations 3, as for example IBM PC workstations. A 
system using the CASE facility of the present invention is not limited to only this hardware configuration. For example, 

is a similar CASE facility can be constructed to develop code distributed in a two-tiered environment, such as a system 
employing only a mainframe and PC workstations or a two-tiered environment comprising a mainframe computer and 
a minicomputer with both accessible by non-intelligent terminals. The CASE facility can be tailored to fit any hardware 
configuration. The basic principles of code generation, the maintenance of a centralized database and the use of a 
rules-based language used in conjunction with other development tools presented by this invention are the same 

20 regardless of a particular hardware configuration. 

Flexibility in hardware configuration is one advantage of the CASE facility according to the present invention over 
those CASE facilities currently available. The CASE facility of the present invention allows flexible architectural designs 
by creating a centralized database called a Repository where the design and the logic of the program module is stored, 
and translated code is distributed from the repository automatically to the different hardware environments. 

25 Typical processors preferred for each of the tiers in the exemplary three-tiered hardware configuration are the IBM 

mainframe sold under the trademark 'Model 3090", running the IBM MVS/XA operating system; the Stratus mini- 
computer sold under the trademark "Model XA2000", running the Stratus Computer, Inc. VOS operating system, and 
the IBM micro-computer sold under the trademark "PS2", executing the Microsoft Corporation operating system sold 
under the trademark "MS-DOS." (For further information on these processors or their operating systems, the reader 

30 is referred to the following publicatbns that are hereby expressly incorporated by reference: "IBM System/370 Bibli- 
ography", document number 6024448; and "Introduction to VOS", by Stratus Computer, Inc., document number R0001 .) 

B. CASE Facility Elements 

35 The CASE facility of the present invention comprises a number of programmed elements, as depicted in FIG. 2: 

a Repository 4; a Rules Language 6; a Communications Manager 8; a Testing/Debugging Facility 10; a PC User- 
Interface Facility 2, including a Rules Painter 30; a Work Station Utility comprising a Work Station Manager 14, a 
Window Painter 16, a Workstation Converse 18; a Documentation Facility 20; and a Systems Generator 22 including 
a Code Generator 20, a Data Access Generator 16, and Systems Assembler 28. Although the programs created by 

40 the CASE facility are centrally -stored, the CASE system program elements may be located in any of the hardware 
environments used in a configuration. 

The Repository 4 is a central database used to store all information about all of the application programs created 
with the CASE facility of the present invention. The Repository 4 could exist in any hardware environment supporting 
a standard relational database. For example on the three-tiered environment shown in FIG. 1 , the Repository 4 could 

45 exist on the mainframe computer 1 , using the IBM relational database management system DB2. 

For purposes of a preferred embodiment of this invention, it is preferred that Central Repository be located in the 
mainframe environment and that the IBM relational database sold under the trademark "DB2" be employed. (For back- 
ground information on DB2, the reader is referred to the following IBM publications which are hereby expressly incor- 
porated by reference: "IBM DATABASE 2 Introduction to SQL" (document number GC26-4082); "IBM DATABASE 2 

50 Reference" (document number SC26-4078); "OS/VS2 TSO Command Language Reference" (document number 
GC28-0646) ; "TSO Extensions Command Language Reference" (document number SC28-1 307); "Interactive System 
Productivity Facility/Program Development Facility for MBS: Program Reference" (document number SC34-2089); 
"Interactive System Productivity Facility/ Program Development Facility of MVS: Dialog Management Services' (doc- 
ument number SC34-2137) and "DB2 Application Programming Guide for TSO and Batch Users.") 

55 The information stored in the Repository 4 includes models provided by the present invention to form the basis for 

an application program and high-level logic modules defined by the present invention for use in the generation of an 
executable program, as will appear. For each program, a data-model and a process-model are developed through the 
use of an entity-relationship modeling system and stored in the Repository 4. The high-level logic modules stored in 
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the Repository 4 are written in a Rules Language defined by the present invention as described below. The information 
is environment independent and is structured to provide a high degree of re-use. 

Programmers input information to the Repository 4, using a standard database language supported by the hard- 
ware. For example where the Repository 4 is constructed from an IBM DB2 database, a programmer would use the 
5 DB2 Structured Query Language, SQL, to model the application. In another example described below, graphic interface 
modules could be provided to the user to input the information. 

The Rules Language 6 is a high-level language that permits users to specify the logic of a program, independent 
of the hardware devices used by the system. Program modules written in the Rules Language 6 are translated by the 
Code Generator 24 into computer code suitable for execution in an environment where the modules are to run. The 
10 Rules Language is described more fully below. 

The Communications Manager 8 performs the run-time transfer ol information between hardware environments. 
For example the Communications Manager 8 would use routers and protocols to handle data transfers between a 
mainframe, a mini computer and PC Workstations. 

The Testing Facility 10, comprising a Rule View Module enables programmers to step through and debug program 
15 code. The Rule View Module can create test data as well as provide regression and stress testing upon an application. 
The Rule View Module is explained more fully below. 

The PC Front-End 12 allows PC based graphic interface to be used for all CASE tool functions. The Rules Painter 
30 permits programmers to construct program modules by manipulating graphic representations of the Rules Language 
statements. The PC Front-End 13 eliminates the need for the programmer to know an operating system language, 
20 such as DOS, by offering all PC functions as menus. 

The Workstation Manager 14 aids in managing user interface in a PC environment. The Window Painter Module 
16 is a tool that helps the developer to create user-interface screens for applications. The Workstation Converse 9 
manages the display and validation of screen information. 

The Workstation Manager Module 1 4 works in combination with commercialized programs to design user-interface, 
25 such as, for example, Microsoft Windows. All of the complexities of using a commercial design tool, like Microsoft 
Windows, are managed by the Workstation Manager 14. 

In designing an application or portions thereof for execution on an "IBM PC," it is preferred that the Microsoft 
Corporation's operating system, sold under the trademark "MICROSOFT WINDOWS," be used. (For more background 
information on MICROSOFT WINDOWS, the reader is referred to the following Microsoft Corporation publications 
30 which are hereby incorporated by reference: "Microsoft Windows Programmer's Utility Guide"; "Microsoft Windows 
Application Style Guide"; Microsoft Windows Programmer's Reference"; and "Microsoft Windows Quick Reference.") 

The Documentation Facility 20 generates all technical documentation for a program under development. Docu- 
mentation includes functional decomposition of the system and hierarchy listings of the Rule Language modules. 

The System Generator 22 includes the Code Generator 12, the System Assembler 28, and the Data Access Gen- 
35 erator 26. The Code Generator 24 translates the Rules Language modules into code in an appropriate programming 
language. The System Assembler 28 brings the various coded program elements together to form an application pro- 
gram. The Data Access Generator 26 allows the program to access date across hardware environments. Code gen- 
eration and program execution is discussed more fully below. 

The PC-front-end 1 2, the Workstation Manager 1 4 and Communication Manager 8, together form a set of Devel- 
40 opment Workbench Modules 34 that enable the user to design the data and process models of an application, and 
rules language modules, and combine them to create a fully functioning application program. 

On the development platform in the exemplary configuration described above, access to all the environments is 
through the PC Front End 5. There developers can code their applications using the Rules Language and the CASE 
facility will automatically generate native code for each environment, as appropriate. 
45 However, for the last phases of development for compiling and testing the applications, its necessary to switch to 

a front-end module for the appropriate execution environment of each one. With respect to those application develop- 
ment activities, each environment is accessed via an environment-specific front end. The environment specific activity 
is described more fully below. 

The Software Distribution System 32 automates and controls migration of an application. The system manages 
50 the release of software to targeted computers. The Software Distribution System 32 solves the problem of synchronizing 
distribution of software located, for example, on hundreds of personal computers. For a more detailed description of 

a Software Distributbn System see International Application No. PCT/US90/ , entitled "Software 

Distribution System;' filed on even date herewith in the name of Norman Shing et al., which is hereby expressly incor- 
porated by reference. 

55 
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90 is related to another Process 92, the relationship is always hierarchical. There are three Process types: Root. Leaf 
and Node. Such relationships define the decomposition of one subsystem into others. The Process Entity 92 is defined 
by the attributes: Process Name, Description, Menu Description, Sub-Process Menu-Type and Sequence Number. 

At runtime, a process 92 runs either as a foreground or background process. A Foreground Process is one that 
s executes interactive communication with the end-user. For example, a Foreground Process may comprise the grpahics 
functions, resident on a PC workstation environment 3, FIG. 1. This is the typical on-line/realtime process. In addition, 
the foreground processes can communicate synchronously with modules on other environments, and they can receive 
unsolicited data, asynchronously. 

A Background Process, once started, will process its input, then stop, or wait for further input. This may be a batch 
10 process for example running on the mainframe, that receives input from a file, or it may be a continuous process that 
runs on-line, for example due that reads from a queue. 

Rules are the procedural specifications of the logic of a Process. This logic is specified in a high-level language 
called the Rules Language. The Rules Language is based on the principles of structured design and programming. 
The syntax of the language along with restrictions built into the architecture ensure a highly modular and concise 
is system specification process. The Rules Language is described in detail below. 

Using Rules Language statements, the CASE facility generates source code for the various environments. The 
CASE facility of the present invention generates all code necessary to perform inter-system communication (for ex- 
ample, when a rule in one environment calls a rule in another), inter-process communication (for example, between 
different processes or regions on the same machine), program-to-program linkage, and user interface. 
20 In the entity-relationship model only information about the Rule is stored in a Rule entity 94 - not the Rule language 

statements. The Rule Entity 94, FIG. 5, FIG. 6, is defined by its attributes: Rule Name, Rule Description, Execution 
Environment; and Mode of Execution (for example, synchronous or asynchronous). 

As with processes there are three categories of Rules: Root, Frontier and Node Rules. A Root Rule is invoked by 
a Process 92. Root Rules do not have user I/O capability. A Node Rule is any rule that is not a Root or Frontier Rule. 
^5 Frontier Rules lie on the boundary of a new computing environment. Those Rules are grouped in a special category 

because Communication Manager 8, FIG. 2, must execute all Frontier Rules and their input/output data has to be 
converted to accommodate changes in environment. 

The Rule Relationships are modeled using Rule Entities 94 and the Uses Relationship 108. 

Components are modules of code written in any third generation programming language known to the CASE 
30 development system such as C, PL7I or COBOL. Components are used to perform functions not handled by the Rules 
Language such as calculations, database access, and calls to operating systems. The CASE facility assumes a "black 
box" structure for Components. A black box has fixed inputs and outputs. Given a specific input, there is always a 
predetermined output. The same analogy applies to Components. Components have explicitly defined inputs and 
outputs. 

35 The Component Entity 96, FIG. 5. FIG. 6 distinct from the component module described above contains the fol- 

lowing attributes: Component Name; Component Description; Language Name (programming language that source 
code of the component is written in); and Execution Environment. 

Windows define user interface. They specify what data are to be accepted from a user, how it is to be displayed, 
and how it is to be accepted. The Window Entity 98 is used to store all information about the user interface. The window 
^0 information is used by the Code Generator Module 24, FIG. 2, and Workstation Converse Module 18, FIG 2. 

A Window Entity 98, FIG. 5 in the entity-relationship model has the following attributes: Window Name, Description. 
The Window Name contains the name of a Panel File also stored in the Repository which contains the information 
necessary to produce graphic interface using a graphic interface program such as Microsoft Windows. 

The View Entity 100, FIG. 5, FIG. 6, is a convenient grouping mechanism for storing data type variables that are 
45 used by the Rules Language. The View 100 is a hierarchical set of named scalar or aggregate values. 

Views 100 are is used in three different ways throughout a typical ystem. A File View 100A represents a template 
of the data constructs saved in a data file. The data constructs used to describe the input and output to Rules and 
Components are Modular Views 100. The data structures used to handle user interface are called Window Views 100. 
Field Entities 102, FIG. 5, FIG. 6, are the basic data elements that comprise the variables used in a program. The 
so Field Entity 1 02 stores all information about data elements, independently of the environment in which the data element 
is used. The Attributes of this entity define the format, editing specifications, report and screen headings, and any other 
generic information about a particular data element. 

A Set 116, FIG. 6 like a View 100, FIG. 5, FIG. 6, is a convenient grouping mechanism that is used to store related 
literals or constants. Value Entities 118, FIG. 6 are symbolic representations of literals or constants. Value Entities 118 
55 provide the ability or refer to specific data values by symbolic or English names. This eliminates the need to hard-code 
specific literal values in Rules. 

Data are stored in files. In a entity-relationship model information concerning data files is stored in the File Entity 
120, FIG. 6. 
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C. Entity-Relationship Modeling 

1 . Entities and Relationships 

5 A feature of the CASE facility of the present invention is the systems model. To design any application using the 

CASE facility, a developer must decompose the application into specified logical parts, and assemble them into a 
program. The data used by a program are stored in Repository 4, FIG. 2, according to an entity-relationship model of 
the present invention. The different parts of an application are expressed as entities and are linked by relationships. 
Defined generally, an entity is something real or abstract about which information is recorded. The information is 

10 organized into a set of characteristics, known as attributes. For example, collected information about employees of a 
company could be placed in an entity type called Employee. The attributes for that entity could be a name, social 
security number, home address, age, birth date, department, etc. An entity called Organization would include attributes 
such as organization name, address, type of organization (such as partnership or corporation), etc. This data is stored 
in a file in the Repository 4 (see FIG. 2). 

is An association between entities is known as a relatbnship. For example in FIG. 3 the entity, Organization 64, is 

now linked to the entity, Employee 58, by the relationship, Employs 66. Relationships are also defined by attributes. 

2. Functional Design 

20 The f unctional design phase begins the modeling task — there are two tasks to perform: data-modeling and process- 

modeling. 

Data-modeling is the method of creating an entity-relationship model for the real-world data to be used by an 
application program. The method involves identifying an entity, such as a corporation, and decomposing that entity 
into subentities and attributes. In FIG. 4, the example entity, Corporation 70, is made up of the sub-entities: Product 
25 72, Staff 74, and Customer 76. Customer consists of the attributes: Name 78, Address 80, and the Entity Order 82. 
The Order entity 82 is composed of the attributes: Number 84, Date 86, and Status 88. 

Once the programmer has modeled the real-world data elements, he or she links them using the relationships 
such as the Employs Relationship 3 illustrated in FIG. 3. 

In model format, the data are stored in the Repository 4, (See FIG. 2). Using the entity-relationship modeling 
30 technique, data for any application can be stored and readily re-used in subsequent applications. 

Process-modeling is the method of constructing a model of an application program, using an entity-relationship 
model. The CASE facility of the present invention requires that all applications be first reduced to an entity-relationship 
model, before a program's logic is specified. The entity-relationship model is not the actual program, it is separate from 
the program modules written in the Rules Language. However, the CASE facility uses the entity-relationship model to 
35 link the various program modules together as well as to construct and distribute the program through a multiprocessor 
system. Entities store information on the flow of a program, the data structures used, the user interface, the environ- 
ments used by the modules and the multiprocessing needs of the program. 

In addition the entity-relationship model provides a representation of the high-level design of the programs from 
the entities. The CASE facility can produce technical documentation from the process model. For a given application, 
the entity-relationship model implicitly represents an amalgamation of a high-level structure-chart and a detailed de- 
scription of the logic and data requirements necessary to make a program run. 

The process-modeling method allows users of the CASE facility to maximize efficiency by re-using program ele- 
ments. The program resulting from the entity-relationship model is highly modular. Because all programs developed 
with the CASE facility presented by this invention use the same entity types and relationships it is likely that many of 
45 the program elements can be re-used. 

D. Application Model Entities and Relationships 

As an example of the present invention, programs built using the CASE facility are broken into ten entity-types 
50 and eleven relationships as shown in FIGS. 5 and 6. For each entity and relationship that defines an application a list 
of attributes and information is kept. 

1. Entities 

55 The Function Entity 90, FIG. 5, is a listing of all the application programs currently on the system. A Function 90 

is defined by the following attributes: Function Name, Test Description and Application Identification. 

A Process 92, FIG. 5, is a logical subdivision of a Function 90. A Function 90 typically is decomposed into two or 
more Processes 92. Processes 92 can be decomposed into tower level Processes 90 (subprocesses). When a Process 
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2. Relationships 

The ten entities representing a program are linked together by one of eleven relationships. 

The Refines Relationship 104, FIG. 5, describes the decomposition of Functions 90 to Processes 92. Its attributes 
s are: Function Name (first participant); Process Name (second participant); and Sequence Number (for menu display). 
Processes also refine into further sub-processes. 

The Defines Relationship 106, FIG. 5, is used to describe the relation between an abstract Process 92 and the 
Rule Entities 94. Its attributes are: Process Name and Rule Name. Processes can also depend upon other processes. 

The Uses Relationship 108, FIG. 5, is used to describe the link between one executable module and another: (e. 
10 g. Rule Uses Rule, Rule Uses Component and Component Uses Component). The attributes of a Uses Relationship 
are: Module Name and Sub-Module Name. 

The Converse Relationship 110, FIG. 5, describes the link between a Module and a Window Entity. The attributes 
of the Converse 110 relation are: Rule Name (first participant) and Window Name (second participant). The function 
of the converse relationship is explained more fully below. 
is The Relationship Owns 112, FIG. 5, connects entities to the Views Entities 100 which describe their logical data 

interfaces. The Rule 94, Component 96, Window 98 and File 120, FIG. 6, entities may own View Entities 100. The 
attributes of the Owns relationship are: Rule/Component/Window or File name; Entity type (either Rule/Component/ 
Window/or file); View Name and View Usage (either In, Out or Inout for user interface I/O). 

The Includes Relationship 114, FIG. 5 connects data items together to form structures. View Entities 100 can 
20 include sub-Views 100 and Fields 102. The Attributes of the Includes Relationship 11 4 are: View Name (first participant 
higher-level view); View/Field Name (second participant); Entity Type (second participant's entity type: either view or 
field); Sequence Number (used to order Sub-Views and Fields); Occurs Number of Times (used to create arrays in 
structures). 

The Owns Set Relationship 124, FIG. 6, links executable modules to the literal set values they refer to. A Rule 
25 may Own a Set by making a local declaration using the Rules Language DCL statement discussed below. The literal 
values will then automatically be included in the Rule Module when the code is generated. A Component Entity 96 may 
also Own Sets 124. The Own Set Relationship Attributes are: Module Name; Module Entity Type (i.e. Rule or Compo- 
nent); Set Name. 

The Contains Relationship 1 26, FIG. 6, link literal data items to a common Set Entity 116. A Set Entity 116 Contains, 
30 for example, 1 8 member Values in the Value Entity 1 1 8. The attributes of the Contains Relationship 1 26 are: Set Name; 
Value; Symbol Name; Sequence Number. 

Finally, the CASE system has file relationships: A File Entity 120, FIG. 6, is Keyed 132 by a Field Entity 122: File 
Entity 120 also Forwards 130 information to another File 120; and a File View Entity 100A Describes 128 a File Entity 
120. 

35 

E. Process-Modeling Reduction Technique 

All Applications developed with the CASE facility can be reduced to a set of pre-selected entities and relationships 
such as the above described entities and relationships. The method begins by defining the Function Entity 90, FIG. 5. 
40 A Function is equivalent to any application program to perform any task or function. The Function Entity 1 contains a 
generalized description of the Application. A Function is decomposed into processes. The processes represent general 
functions that the program must perform. 

For example, one of the Process Entities 92 in a application to perform stock market trading could be entitled 
"Futures Trade Entry." A Process Entity 92, FIG. 5, stores information describing the process. Processes can be de- 
45 composed into further processes. On each decomposition the information about the new process is stored in a Process 
Entity 92. 

The Function Entity 90 and the Process Entities 92 create a high-level overview of an applicatbn. During the 
modeling phase the CASE facility presented by this invention provides tools to aid development. The programmer can 
use CASE provided graphics to specify the Process 92 and Function 90 Entities and Refine Relationships 104. The 
so user sees functions and processes listed on menus. The CASE facility also assists the analyst and user in process 
modeling by allowing this Function/Process decomposition to be prototyped interactively as for example with an analyst 
and a programmer. The analyst can enter his thoughts, generate menus reflecting the input, and solicit input (modifi- 
cations) from the programmer as to whether this is in fact the way the user envisions the way a problem is to be solved. 

Once the application problem has been reduced to a series of Function Entities 90 and Process Entities 92, tech- 
S5 nical design begins. In technical design the program coding specifications are described through the Rule 94, Com- 
ponent 96 and Window 98 Entities. 

The important aspect of Technical Design is the specification of the Rules and Components, Windows, and Views 
that are necessary to run the program. FIG. 7 is an example of Process flow diagram using entity-relationship modeling 
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standards. The Square boxes in the figure, 134, 136, 138, 140, 142, 144, represent Process and Function Entities. 
The capsule-shaped boxes, 148-182, represent Rules. The oval-shaped boxes, 184, 186, 192, 194, 196, represent 
Components. The circles, 188, 190, represent Windows. The process flow diagram is used to specify the information 
contained in the Rule 94, Component 96, Window 98 and View 100 Entities (see FIG. 5) as well as the Relationships 
s between them. 

Referring now to FIG. 2 there is illustrated Development Workbench Modules 34, used to generate the entity 
relationship model and rules language code. FIG. 2A illustrates an exemplary implementation of the Modules 34 in a 
three-tiered system, wherein the Development Workbench Modules 34 reside in the PC Environment 3. The Develop- 
ment Workbench Modules 34 comprise a series of graphic-based tools that help a user design and implement an 

10 application by providing a pre-selected set of entities and relationships and a rules programming language. Everything 
that a user designs using the Development Workbench Modules 34 will be stored in a Local Repository 60 in the PC 
Environment 3. Eventually, the data in the Local Repository 60 are used to populate the Central Repository 4, which 
resides on the mainframe 1 environment. Everything that constitutes documentation or implementation of a system 
must be defined to the Central Repository 4, during the development cycle. Ultimately, the application is distributed, 

is for example, to end-user PC workstation environments 3 (and other environments as appropriate) from the Central 
Repository 4. 

However, use of the Development Workbench Modules 34 need not be connected to the Central Repository 4 at 
all times. For performance reasons, it is advantageous to avoid constantly querying the Central Repository 4 for infor- 
mation. Uploading from and downloading to the Central Repository 4 is done via the Communications Manager 8 that 
20 accesses to the Local Repository 60. 

The Local Repository 60 is a storage device located in the PC Environment 3. A Database Engine Module 54 
comprises software to store information and access it. A Local Repository Engine 52 provides the user access to the 
Development Workbench Modules 34 and enables the Development Workbench Modules 34 to access the Local Re- 
pository 60 via the Database Engine Module 54. 
25 A Hierarchy Diagrammer Module 38 is provided in the Development Workbench Modules 34, to enable a user to 

specify the data and process modules that provide the logical foundation for the application program. The Hierarchy 
Diagrammer Module 38 could for example include an Entity-Relationship Diagrammer which could be used for data 
modeling - i.e. specifying the entity relationship model for the real-word data that will be used by the application 
program. With the Entity Relationship Diagrammer, a user can graphically identify entities and decompose the entities 
30 into sub-entities and defining attributes. For example, in FIG. 4, a Corporation 70 was decomposed into sub-entities 
Product 72, Staff 74 and Customer 76. The Entity Relationship Diagrammer provides modules to graphically specify 
such entities and relationships. 

The Development Workbench Modules 34 could also include a Matrix Builder Module 42 that enables a user to 
store, in matrix form, mappings between different types of entities. The matrix mappings are typically used in the 
35 strategic planning phase of analysis to capture the relationships between data and process flow. The matrix created 
will also be saved in the Local 60 and Central Repositories 4. 

Window Painter Module 16 enables a user to create panels, which are the interface through which the end-users 
of an application interact. The Window Painter Module 16 panels determine the "look and feel" of an application. 
Using the Window Painter Module 16, the user can either create a new Window File for the related window entity 
40 or modify a previously created Window File that was stored in the Repository 4. 

Using the example of a PC that is processing with the Microsoft Windows operating system, the Window Painter 
Module 16 provides the software necessary for a user to create graphic interface in that environment. 

For example, a user could access the Window Painter Module 16 from the Development Workbench, where a 
blank window could appear. A user could then select a list of windows files previously defined in the Local Repository 
45 60. Clicking on one of these Window names will bring up a panel upon which you can "paint" the objects that will be 
presented to the end-user of the user's application. 

In addition to the panel screen, there are primarily two types of objects to manipulate: entity objects and local 
objects. 

Entity objects are Field 102 and View 100 Entities that have been defined and reside in the Local Repository 60. 
50 A Views menu can provide a list of View Entities 100 that are attached to the Window that a user is painting, followed 
by the selectable Field Entities 102 and multiply-occurring sub-views that are in turn attached to them. A user can 
select any of these available objects, place them on the panel, and customize them. 

Fields could appear as empty bracketed boxes with a screen label to the left. The value ol the Field (if any) appears 
between the brackets at runtime. The screen label was defined when the Entity was created and is associated with 
55 the Field in the Repository 4. A user can edit the screen label as a text object on the panel. If the screen label field of 
the Field entity is blank, then the Field short name is used instead. 

These objects could be moved about the panel by clicking on the object and holding down the mouse button while 
dragging the object to the desired location. 
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Local objects are associated with the panel but are not defined to the Local Repository 60. The user could select 
Local Objects from an Objects menu. 

There are three types of Local Objects: 

Control Objects, which can be selected by the end user, with a mouse. Control Objects include pushbuttons, 
pushboxes, menu bar items, and pulldown items. Text Objects, which can be placed on the panel as labels or instruc- 
tional messages. 

By controlling placement of the screen objects, a user can build a window associated with a View Entity 100, and 
save that window specification for routine applications in the Local Repository 60 and in the Central Repository 4. The 
window files created in this example will be used to create the user interface of an application program. The converse 
function described more fully below provides the software modules to link the user specified window file to the windows 
provided graphic interface routines. 

The Rules Painter Module 30 provides the interface to allow users to create Rules Language Modules that are 
associated with the Rule Entities 94. The Rules Language Modules and Rule Entities are linked. Each Rule Entity 
contains information concerning the functionaity of the rule and the name of a corresponding Rules Language Module. 
The corresponding Rules Language Module contains statements to execute the functionality of the linked Rule Entity. 
Typical statements comprising rules language are described more fully below. 

The Report Painter Module 40 is used to design formats for end user reports in a manner similar to that of specifying 
windows for graphical interface using the Window Painter Module 16. 

The Database Administration Module (DBA) 44 is a communications facility that enables a user to refresh data in 
the Local Repository 60 and upload changes to the Central Repository 4. The DBA Module 44 is also used to generate 
reports about the contents of the Local Repository 60. This module uses the Local Repository Engine 52, the Database 
Engine 54 and the Communications Manager Module 8 in the PC Environment 3 to access data in the Local Repository 
60, and send and receive data from the Central Repository 4. Using the DBA Module 44, objects and attributes can 
be selected from the Repository 4 for alteration or deletion. The DBA Module 44 includes a system security component, 
requiring users to log in to the mainframe environment 1 and only certain classes of users can have authorization to 
delete specific objects. The refresh feature enables users to download objects from the Repository 4. 

The Development Workbench Modules 34 enables users to specify the data modelling necessary to specify the 
entities and relationships, as well as to input the rules, components, views, field and window panels necessary to create 
the final executable program in later development steps. Using the Development Workbench Modules 34 these logic 
structures can be stored in the Repository 4. 

F. Constructing the Program 

With the Entity-relationship model in place program construction can begin. Source code is generated from the 
Rules Language Modules, Components, Windows, Files, Fields, Views, Values and Sets that are stored in the Repos- 
itory. Rules, Components, Windows and Files are Program Modules distinct from the Rule Entities 94, Component 
Entities 96, Window Entities 98 and File Entities 120 linked in the entity-relationship model (see FIGS. 5 and 6). Those 
Entities store information about the actual program modules from which the application program is created. 

At this stage of construction much of the work in constructing the program modules is done. The data structures 
are defined by the View 100, Field 102, Set 116, and Value 118 Entities. The Code Generator Facility 24, FIG. 2, copies 
these entities into the program modules that are related to them by the Rule 94 and Component 96 Entities (see FIG. 
5). Component Modules do not need to be built by the programmer, as they are previously programmed subroutines 
provided by the CASE facility to perform basic mathematical operations and operating system access. However, the 
CASE facility permits new components to be constructed and stored in the Repository 4, FIG. 2. The process of code 
generator is described more fully below. 

1. Re-Usability Analysis 

Even before the creation of the Rules Language Modules, using, as for example, the Rules Painter Module, the 
CASE facility speeds program development, because it provides a method to re-use previously generated code. With 
entity-relationship modeling, much of the same logic from one application can be re-used in other applications. It is 
easier to re-use code that has already been developed and tested than to re-create it. Keeping this in mind, a re-use 
analysis should be performed. 

With the entity-relationship model stored in the Repository 4, FIG. 2, the Entities can be queried for usage by other 
Entities. For example, with the Repository 4 existing on a database supported by IBM DB2, a Where Used query on 
the Field Entity 122, FIG. 5, returns a list of all the View Entities 100A using that Field Entity 122. The usage of the 
View Entities can be queried further to establish what Rules, Components or Windows use those View Entities. This 
method allows programmers to discover previously coded Rules and Components. A Find Where query will search all 
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entity attributes throughout the entire database for particular words or character strings. 

In addition the CASE facility allows programmers to define a keyword for all Rules, Components and Field created. 
A Search command can be performed to locate entities possessing a certain keyword. A programmer can perform 
sophisticated searches such as find all keywords starting with, for example, "CIT and ending with n Pp". 

Once a programmer has located a module that may be re-usable, he or she can get further information by browsing 
the description or other attributes associated with the entity. 

2. The Rules Language 

The Rules Language is a high-level programming language which supports all standard flow of control constructs. 
What is unusual about the Rules Language is that it does not require a means of describing elaborate data structures, 
and it has data constructs which access information in the entity/relationship modules. The description of all the data 
structures used by a program within the CASE facility is stored in the View and Set Entities in the program's entity- 
relationship model. All Rules used by a program share data structures. The sharing of data structures provides strict 
coordination between the data passed from one Rules Language Module to another. This technique avoids one of the 
major sources of program errors ~ a mismatch between the data passed between subroutines. 

A Rule consists of zero or more declare statements followed by zero or more executable statements. 

A data type declared must be one of the following type: Smallint, Integer, Char, Varchar, Decimal, Signed Picture 
or Like (an already declared Item). The declare statement is in the form. 

DCL 

declaration; [declaration; . . . ] 

ENDDCL 

where the declaration is: 



identifier [(■)][, identifier [ (s) ] , ...] 
declare type or EXTERN identifier [, 
identifier, . . • ] 
SET 

The data types are more fully explained in Appendix C attached hereto. 

The Rules language supports three types of executable statements: 1) Assignment statements; 2) External flow 
of control statements; and 3) Internal flow of control statements: 



Assignment Statements 


External Flow of Control Statements 


External Flow of Control Statements 


MAP 


USE 


IF 


OVERLAY 


RETURN 


CASEOF 


CLEAR 


CONVERSE 


DO 




ASYNC 





Assignment statements alter the data contained in and held by program variables. The MAP Statement places an 
expressed value in a variable location. The OVERLAY statement replaces the contents of a variable with specified 
data item. The CLEAR Statement replaces numeric fields with zero values and character fields with space values. The 
syntax of the assignment statements is: 

MAP expression TO variable 

OVERLAY data item TO variable 

CLEAR variable 

Four statements in the Rules Language handle the external flow of control between program modules. The USE 
statement enables one program module to invoke another Rule or Component. It is similar to a subroutine CALL 
statement in other programming languages. The syntax is: 
USE MODULE Component 

USE RULE Rule [ NEST ] The Next option indicates that all Windows invoking the Rule will come in -pop up" 
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mode; i.e., it will be displayed over the screen that was previously displayed. 

The RETURN Statement transfers control back to the Rule that executed the USE statement: 
RETURN. 

The CONVERSE statement provides communication between PC-based rules and the user interface. A typical 
s converse statement is: 

CONVERSE WINDOW window 
The converse statement invokes at runtime several modules provided by the present invention to physically execute 
the converse relationship between window and rule. In the example of a PC resident rule accessing a PC based window, 
the converse modules would reside in the PC environment 3 and interface the operating system of that environment 
10 to provide graphic user interlace. 

The function of the converse modules is to manage all the screen input and output for a rule. The modules send 
to the rule the user's input by populating a specified field. Prior to passing the end-users input to the rule conversing 
the window, the converse modules perform edit checking and validation of every input field specified by the attributes 
defined in the repository. If for example there was a specified set of values related to a rule for a given field (e.g. if a 
is color field could only equal "red" or 'blue" any answer "green" would be an error). 

In creating the user screen, it is also the function of the converse module to interface with the operating system 
to output the user interface screens specified by the window files. 

The Rules Language supports Asychronous data flow with the ASYNC statement. For example, in a system using 
a Stratus mini computer performing in parallel, unsolicited data allows a Stratus-based Rule to send data to a PC- 
20 based Rule. This is supported using the following statements: 

- ASYNC ATTACH 

- ASYNC DETACH 

- ASYNC REFRESH 
25 ~~ ASYNC ROUTE 

The ASYNC ATTACH command will initiate the receiving of unsolicited input as for example by a PC-based Rule sent 
by a Stratus-based Rule. The ASYNC DETACH command performs the exact reverse of ATTACH. It may only be used 
after an ATTACH command, at which point it will discontinue the receiving of unsolicited input. The ASYNC ROUTE 
30 command switches data refreshing from one PC Rule to another. The ASYNC REFRESH statement will induce auto- 
matic updating of a specific field, so long as the Attach Statement has been used. 

The Rules language has three different statements to order the flow of control within a Rule. 

An IF statement controls execution based on a specified condition: 

35 

IF condition [ executable stmt ... ] 
[ ELSE [ executable stmt . . . ] ] 

ENDIF 

40 

The CASEOF statement selects one of several alternative execution paths based on the value of a variable. The 
syntax is 



4s CASEOF variable 

CASE constant [ constant ... ] [ executable 
stmt 

... ] 

[ CASE constant [ constant ... ] [ 

so executable 

stmt ... ] 

[ CASE OTHER 

EN DC AS E 



A DO statement controls the execution ol repetitive loops. The syntax is 
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DO [ FROM data item ] [ TO data item ] [ 
BY data item ] [ INDEX variable ] [ 
executable stmt • . • ] 

[ WHILE condition [ executable stmt • • • ] ] 
ENDDO 

All data items and variables specified to execute a DO loop must be integer numbers. The defaults for the DO 
statement are: FROM = 1 , TO = n, BY = 1 , where n is an integer. 

Conditions occur within the IF, CASEOF, and DO statements. A simple condition is: 
expression logical operator expression or expression INSET Set 
where logical operator is one of the following: 




A condition is built from simple conditions or other conditions: 





simple condition 


or 


( condition ) 


or 


NOT condition 


or 


condition AND condition 


or 


condition OR condition 



The INSET statement is used to determine whether a given variable or constant appears as a value within a SET 
For example suppose X is a data item whose data type is compatible to the data type of the set: 

X INSET SET NAME is a condition which evaluates to either TRUE or FALSE depending on whether or 
not at least one of the values, in SET NAME matches the value of X. 

A programmer uses the Rules Language statements to write out the logic o1 the program. For further information 
on the Rules Language, reference should be made to Appendices A-F attached hereto. 

3. User Interface Windows 

The user interface for any application is constructed using the CASE facilities Window Painter 8, FIG. 2. As de- 
scribed above, he Window Painter Module 16 is the program designed to help build user interface in a given operating 
system. In the example of the PC environment above the rules painter would interface with the Microsoft Window 
Operating System. The Window Painter Module 16 would then feature the mouse-based use interface. 

The Window Painter Module 16 is also used to create screen mappings of data designated in the Field 102 and 
View Entitles 100 (see FIG. 5). The Window Painter Module 16, FIG. 2, creates a file. That file contains data to create 
a screen mapping of the Window View. After creating and saving the panel, the CASE facility of the invention also 
generates other files, such as for example a file that contains the code for the "painted" panel. Another file could contain 
the code for the menu structures used by a panel. 

G. Code Generation 

Once an application has been modeled, and the Rules, Components and Windows have been created, the CASE 
facility produces source code. 

Preparation is the code generation phase. When an application is prepared, the View 100 and Set 116 Entities, 
FIG. 5, are used to create copybooks. A copybook is a file which is copied into the source code of a program module. 
The CASE facility creates a copybook for each data structure and includes a copy of that file in every executable Rule, 
Window or Component related to a particular View or Set. 

Preparation also generates environment-specific source code for each Rule Language module. The Rule Entity 
94, FIG. 5, contains an attribute specifying the environment destination of each Rule Module. The Code Generator, 
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24, FIG. 2, takes high-level Rules Language statements and translates them into source code in a language supported 
by the hardware environment of the Rule's destination. For example, it a Rule was to be executed on a Personal 
Computer that supported only the C language, the Code generator would translate the Rule Language Statements In C. 

It the Rule Language statements specified in a module can be successfully generated into source code, the code 
is stored in files in the Repository 4. However, if there are logical errors in the Rule Language statements, no code is 
saved and error messages detailing the unsuccessful result are saved in a Failed Results File. 

Once preparation has been performed, detailed reports can be made for each Entity in the entity-relationship 
model. Those reports are a program's technical documentation. 

The reader is referred again to FIG. 2A which depicts an example of an implementation of the Code Generation 
Module 24, FIG. 2 in the three-tiered environments of mainframe 1, minicomputer 2, and PC 3. In that example the 
source code for each of the Rules Language Modules, need not be generated in the hardware environment that will 
be each rule's destination; however, the step of compilation of that source code would occur in the destination envi- 
ronment of the corresponding rule. In the PC environment 3, a Prepare Facility 59, FIG. 2A could prepare, lor example 
C language source code, for each PC executable rule using the Rules Language Code, and all view fields and com- 
ponent windows associated with that rule module's rule entity. The Prepare Facility 59 could also generate for example 
COBOL source code for rules designated to execute on the mainframe. In the mainframe environment 1 , a mainframe 
front-end module 57 provides the ability to translate the Rules Language Module statements to the source code lan- 
guage statements supported by the hardware environment of that rule's destination. The System 88 HPS front-end 
module 56 performs the same task in a minicomputer environment. 

To perform code generation in the example, the code generation module in each environment uses the rules lan- 
guage modules plus information needed from the entity relationship model. To transport the Rules Language Modules 
and generate source code modules to the different environments, the user can, using the database administration 
module (DBA) 44, upload the module files to the Central Repository 4, and then, using separate modules 34, 46 to 
download the information to specific environments for compiling. 

In the case of a rule designed to execute on the mainframe environment 2 from the PC environment 3, a main 
view module 36 provides access to the mainframe environment 1 , via the communications manager module 8, creating 
an emulation of a non-intelligent terminal in the PC environment. 

From the PC environment 3, access to the minicomputer environment 2 in this example is provided by a Talk View 
Module 46, which communicates with the System 88 Front-end Module 56 using a PC connect module 50, and file 
translation module 48. At this stage of development, each generated module's source code statements can be exam- 
ined with a Rule View Debugger associated with each respective environment. The Rule view Debugger is an aspect 
of the Testing Facility 10 of the present invention and is described more fully below Successfully tested modules can 
be stored in the Central Repository 4. 

I. Assembly 

When all the source code modules of an application have been distributed to each environment, they must be 
assembled into a running computer program. The steps are to: 1) Compile the source code into object code; 2) Enable 
communication routines to allow interaction of program modules across environments; and 3) Bind or link the compiled 
code. 

Assembly must be executed in each environment where program modules were distributed. For example, on a 
system incorporating PC processing, the PC will have a PC-based System Assembler 28, FIG. 2, that will enable a 
programmer to compile and bind the PC-based rules. 

In the same example, separate assembly would have to be completed on a mini computer. For example on a IBM 
S/88 or Stratus mini computer, a command such as "Build the Rule Router Application" would take the Frontier Rules 
and link them to every other Rule modules related to it in the mini-environment. The function also binds the code into 
an executable module. 

Mainframe program modules are separately assembled. For example, in the exemplary IBM environment support- 
ed by the CICS operating system and DB2 relational database, a mainframe-based System Assembler 28, FIG. 2, 
provides assembly functions for the Rule and Component source code. For a Rule, an assembler would: 

~~ verify that the Rule is a valid mainframe rule; 

— verify that the Rule has completed the code generation process; 

~ prompt the user to indicate if the Rule is to be setup as a Frontier Rule; 

- read the Bind file to load the on-line Views File and the on-line Relationship File for runtime PCI and Conversion use; 

— load the source code to the online Source file for rule View use; 

- automatically perform the DB2 Bind based upon the relationships defined to the Repository for Frontier Rules that 
use Components which issue DB2 calls; 
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~ display a list of other Rules and Components affected by the setup of a particular Rule; 

~- assign a unique Identifier and a unique DB2 Plan name for Frontier Rules that use Components which issue DB2 
calls; 

~ Rebind a DB2 Plan for a Frontier Rule when one of the Rule's related Components, that issue DB2 calls, has been 
5 modified; 

- remove the rule from the mainframe environment when the Rule is no longer needed; 
A Component assembler in a mainframe environment would perform these functions: 

10 — provide the facilities for a programmer to compile his Component in a language supported by the system; 

- allow the programmer to view the results of his compile (compile listing and link edit map); 

~ display a list of other Rules and Components affected by the setup of a particular Component; 

- allow the user to edit the source code of a mainframe Component; 

is j. Execution 

Upon successful assembly of the application modules in each hardware environment the program can now be 
executed and tested. The CASE facility provides the ability to execute and test the application from any environment 
in the hardware architecture. For example, using the hardware architecture comprised of an IBM Mainframe, an IBM 
20 Stratus mini computer and PC workstation, as in FIG. 1 , a programmer seated at a PC would have the option to: 

- Execute the PC based portion of an application; no links will be created with modules executing in Stratus or 
Mainframe other environment; 

- Test the modules and modular executing in one other environment. In this case links are created with utilities other 
2S environments. This permits communication between environments; 

- Execute or test the entire program. In this case links are created with each of the required execution environments. 

K. Revising an Application 

30 The process of changing the elements in an application using the Entity/Relationship Modeling system and the 

Rules Language is a straightforward process. The database is entered and the program element is changed. However, 
small changes in this system can have large consequences. In general any entity type that Owns. Uses, or Includes 
Entities that have been changed will have to be reprepared or "Modified". The CASE facility accomplishes the modifi- 
cation through the Software Distribution System 32, FIG. 2. (See the aforementioned International Application incor- 

35 porated by reference, supra.) 

L. Testing Facility 

Finally, the CASE system provides debugging and testing facility that enables users to evaluate the performance 
40 of a application. 

Generally the applications are first inputed on the computer at code level. Traditional code debugging tools are 
designed for testing at the code level only. Instead, the CASE facility of the present invention provides a Rule View 
Module for high-level debugging which is part of the Testing Facility 1 0 depicted in FIG. 1 . A version of Rule View would 
exist in each of the operating environments in a hardware configuration. Applications spanning more than one envi- 
es ronment require a separate testing for the modules in each environment. 

Calls to the Rule View Module are automatically embedded by the CASE facility when code is generated. Rule 
View runs the application in a Rules-level debugger locating errors and problems that occur. It can be used interactively 
to step through a Rules process and examine the contents a View Copybook at any point. Rule View gives programmers 
the ability to: 

50 

1. Initiate the execution of a Rule; 

2. Break the interface between a Rule and a Second Rule or Component; 

3. Step into the logic of a Rule; 

4. Step over Rule or Component Module; 
55 5. Step back to the beginning of a Module; 

6. Examine and modify any Field within a View owned by the active Rule; 

7. Review the active Rule's source code: 

8. Save any View data for future reference and re-use; 
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9. Print the Rule source code and View data. 

Rule View will assemble at each breakpoint, a list of Views that can be examined and edited. The number of Views 
displayed depends on where and how Rule View is used. In most cases, the Views available tor display will contain 
5 the input, output ot the Rule being executed. In more advanced situations where asynchronous Rules are being 
debugged or multiple applications are being tested -- many Views may be available for examination. The contents ot 
a View can be printed or saved in a file. 

The Rule View editor permits the programmer to edit any data by using a Field Editor. With the Field Editor, a 
programmer can change any data by typing over the old information. The editor also permits the user to restore the 
10 contents of any field to its original value. 

To review a Rule's source code, a Text Editor provides an option where the line of source code currently being 
executed is highlighted at all times. If multiple modules are running under Rule View, the source that is displayed will 
be the source code that Owns the data in the current View. 

f5 M. Software Distribution for General Use 

The previous discussion of the CASE tool facility of the present invention was limited to the modeling and devel- 
opment of a single copy of an application program, distributed, as for example, access the three hardware environments 
of a PC, a minicomputer and a mainframe. A single copy of the modules comprising the program was distributed to 

20 the appropriate hardware environments, and the application was debugged and its performance was rated. However, 
once the application is tested and ready for general use many copies of the modules comprising the program need to 
be distributed and maintained. The Software Distribution System Module 32 of the present invention will distribute 
multiple copies of the modules of an application throughout a parallel processing hardware environment, so that many 
users can use the same program. For more information on the Software Distribution System see the aforementioned 

25 International Application. 

N. Non-Intelligent Terminal Converse (NITC) 

In addition to the hardware configuration mentioned above, the CASE facility of the present invention can be also 

30 implemented using a hardware configuration in which the u ttimate user of the application program does not have access 
to a processing terminal, such as a PC. Instead, the end-user would have access only to a non-intelligent terminal. An 
example would be an IBM brand 3270 terminal connected to a mainframe computer such as the IBM 3090, specified 
as an exemplary embodiment above. However, other appropriate terminals can be used when implementing the in- 
vention on other mainframe hardware environments. A non-intelligent terminal is used sometimes, because it is less 

35 expensive for a massive user group to access a single mainframe processor, rather than giving each user his or her 
own personal processor. In these instances, however, it might be that the programming specialists would still develop 
applications with a PC, using the same Development Workbench Modules 34 as described in FIG. 2A. Those devel- 
opment tools permit the programmer, for example, to build user interface files (i.e. window files) that are used in con- 
junction with the CASE facility converse function described above. Given that the end-user in the case above has no 

40 PC to converse the created windows, the graphic interface specified in the windows files would be useless. 

However, the present invention provides a feature to create a graphical interface using a non-intelligent terminal 
converse (NITC) Module 140, FIG. 2A. The non-intelligent terminal converse module makes it possible to build appli- 
cations that display graphic user interface to an end-user using, for instance, a non-intelligent device connected to a 
mainframe. The non-intelligent terminal converse module can also convert existing PC workstation software modules 

45 so that they can execute on a mainframe environment. By providing this function in the present invention, a mainframe 
executing application can be designed, constructed, debugged and prototyped completely within a PC environment, 
using the Development Workbench Modules 34, without accessing the mainframe until public distribution. 

In the entity relationship model, the window entity is still specified for a window file that will be used for graphic 
user interface on the mainframe. 

so in the PC environment the Development Workbench Modules 34 enable a user to paint the window objects (called 

panels) with which the end user of the application interacts. The Window Painter Module is discussed above. 

The panel can be stored in the Central Repository 4 as a file associated with the Window entity. However, these 
panels must be designed using screen objects that can be supported on the non-intelligent terminal converse terminal 
device. 

55 A window to execute on both the PC and non-intelligent terminal can be specified for example by selecting an 

option in the Window Painter Module 1 6. The choice of the option converts the current Window into a format that mimics 
the non-intelligent terminal converse screen. For example, Fields could be translated to row/column coordinates, Push- 
buttons could be moved to the bottom of the screen and require keyboard equivalents. Selecting this choice also sets 
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the Window Painter Module in a non-inteiligent terminal panel building mode that prevents the placement of new objects 
that cannot be supported by a non-intelligent terminal converse terminal device. 

The major difference between a PC Workstation and a non-intelligent terminal device is that the non-intelligent 
terminal converse device manipulates text characters, while PC Workstation manipulates graphic pixels which gives 
$ the PC Workstation a greater degree of control. To account for this difference, the Window Painter Module could, for 
example, convert all text objects to a standard font. 

The Windows created in the mainframe environment support many of the features that would be present in PC 
environment Windows, including e.g. colors, editable and text Fields (i.e., for display only), Field display attributes (e. 
g., size or type of Field, range, etc.), Pushbuttons and other function key equivalents. 
10 Following the construction of the Application on the PC Workstation, the objects that make up the application must 

be uploaded to the Mainframe to be prepared for execution. 

The run-time portion of the Non-Intelligent Terminal Converse module manages all the converse functions and 
provides the facilities for a developer to dynamically modify the converse functions. 

The primary function of the converse modules is to manage all the non-intelligent terminal screen input and output 
'5 for a Rule conversing Window. In addition, the non-intelligent terminal converse module communicates the end-user's 
actions to the Rule by populating a selected field with the selected text string. Prior to passing the end-user's input to 
the invoking Rule, the converse module performs the necessary edit and validation of every input Field as specified 
by the attributes defined in the Repository and in the Window definition. 

The non-intelligent terminal converse module is invoked every time a Rule converses a Window. When a Rule 
20 converses a Window, the non-intelligent terminal converse module reads a pre-determined file to obtain the physical 
attributes of the Window. These physical attributes are used to construct the data stream commands used to display 
the Window on a non-intelligent terminal device. 

The non-intelligent terminal converse module performs edit and validation of all input Fields prior to returning 
control to the invoking Rule. For all numerical Fields, the non-intelligent terminal converse module ensures that the 
25 data entered is numeric and adjusts the significance based upon an entered decimal point or the implied decimal point 
specified in a numeric picture string. 

For example, if a decimal Field is defined as five digits in length with two of the digits to the right of the decimal 
point and edited using a numeric picture string of "9999.9", a string of 123 entered into the Field will have the following 
results. The decimal Field will contain the value 12.30 and the screen field will display 0012.3. In addition to using 
30 numeric picture strings to edit and validate numeric input, a range limit can be set using the Window Painter Module 
to ensure that the numeric value entered is not beyond the minimum and maximum values of the specified range. 

Character Fields are only validated if they are the input value matches by a Set of permissible values. This Set 
and its values are defined as entities to the Central Repository. To set a Field to require a set of permissible values, 
the name of the Set entity must be specified in the Field's Reference File Attribute when setting the Field's Object Edit 
35 Specifications using the Window Painter Module. The non-intelligent terminal converse module will verify that the en- 
tered character string is contained in the set of permissible values. 

For any fields in error, the non-intelligent terminal converse module will flag the fields in error and will display an 
error message. For non-intelligent devices that support color, the fields in error could be highlighted. 

As stated earlier, the pushbutton objects on the PC Workstation Window could be implemented on the non-intel- 
40 ligent terminal device as a Function key. Each function key defined for a Window will have a text value associated with 
it. This text value will be returned to the invoking Rule in a specified Field by the non-intelligent terminal converse 
module. 

The above described embodiment of the invention is meant to be representative only, as certain changes may be 
made therein without departing from the clear teachings of the invention. Accordingly, references should be made to 
45 the following claims which above define the invention. 

APPENDIX A: RULES LANGUAGE SYNTAX 

Tokens of the Rules Language 

50 

Tokens are the atoms from which a programming language is built. All reserved words such as IF, AND, FROM, ... 
represent tokens of the Rules Language. Other examples are special symbols such as ")° (right parenthesis), '<=" 
(less or equal relational operator), and the like. Finally you will also encounter tokens such as DICT_view (View Name) 
which denote references stemming from the Repository. 
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Reserved Words 



5 



10 



15 



20 



30 



40 



ABS 


EVERY 


OVERLAY 


ALL 


EXISTS 


PC 


AND 


EXP, EXP 10 


PREV 


ASCENDING 


EXTERN 


PUT 


ASYNCH 


EXTRACT 


QUEUE 


ATTACH 


FALSE 


REFRESH 


AVG 


FIELD 


RETRIEVE 


BEEP 


FLASH 


RETURN 


BY 


FOR ALL 


RIGHTJ 


CASE 


FROM 


ROUND 


CHAR 


IF 


ROUTE 


CICS 


IN 


RULE 


CLEAR 


INDEX 


SET 


COMPONENT 


INSET 


SETERROR 


CONVERSE 


INTEGER 


SMALLINT 


CURRENT 


LEFT J 


SPACES 


DCL 


LENGTH 


SQL 


DELETE 


LIKE 


SQRT 


DEPENDING 


LOG, LOG 10 


STRATUS 


DESCENDING 


MAP 


STRING 


DETACH 


MAX 


SUBSTRING 


DIV 


MIN 


SUM 


DO 


MOD 


TO 


DOMAIN 


MODULE 


TRIM 


ELSE 


MOVE 


TRUE 


EMPTY 


NEST 


TYPE 


ENDCASE 


NEXT 


USE 


ENDDCL 


NOT 


VIA 


ENDDO 


NUMERIC 


VIEW 


ENDEXTERN 


OCCUR 


WHILE 


ENDFORALL 


OF 


WINDOW 


ENDIF 


ON 


ZERO 


ENDSET 


OR 


ZEROES 



Reserved Symbols 



45 



50 



Characters 


Description 


Symbol 


*> 


Lett comment 




<* 


Righl comment 




( 


Left parenthesis 


LP 


) 


Right parenthesis 


RP 




Equal 


EQ 


>= 


Greater or equal 


GE 


> 


Greater than 


GT 


<= 


Less than or equal 


LE 


< 


Less than 


LT 


<> 


Not equal 


NE 




Comma 


COMMA 
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(continued) 



Characters 


Description 


Symbol 




Semicolon 


SEMI 



Repository Entity Identifiers 

MODULE_NAME 

RULE_NAME 

Wl N DOW_N AME 

VIEW_NAME 

SYMBOL_NAME 

SET_NAME 

t5 PRECEDENCE TABLE 



The following precedence table lists the precedence or binding power of the Rules Language operators in increas- 
ing order. Operators which occur on the same line have amongst themselves the same binding power. 



OR 


left to right 


AND 


left to right 


NOT 


right to left 


EQNE LELTGE GT 


non-associative 


INSET 


non-associative 


MINUS 


left to right 


IN 


non-associative 


OF 


right to left 



The right column describes the associativity of the operations. We can see from the "AND line' of the precedence 
table that it is perfectly legal to write for conditions condl , cond2, cond3 

condl AND cond2 OR cond3 
and that implied order or parsing is first 

condl AND cond2 
and afterwards 

cond2 AND cond3 
another example: Given a partial qualification 

V1 OF V2 OF V3 

involving three Views V1, V2, V3 then the parser first recognizes 

V2 OF V3 
and afterwards 

V1 OF V2. 



45 



50 



55 
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APPENDIX B: RULES LANGUAGE GRAMMAR (BNF) 

5 

10 

15 
20 
25 
30 
35 
40 
45 
50 
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rule_code: 
del s-list: 

i 

dcl_stmt : 
del 1st: 

I 

dcl_item: 

dcl__idx-item: 
dcl_chr_item: 
dcl_int item : 
dcl_like_itero : 
dcl_ext_item : 
dclvar list: 

" i 

dclvar item: 

~ i 

chrtype: 

inttype: 

liketype: 
dcl — subscr: 
dicttype: 
stmt list: 

" i 

stmt: 



dcl_s_l i st stmt_l ist 
empty 

dcl_s_l ist dcl_stmt 
DCL dcl_lst ENDDCL 
dcl_item 

dcl_lst dcl_itero 

dcl_idx_item 

dcl_chr_item 

dcl_int_JLtem 

dcl_like_item 

dcl_ext_item 

dclvar_list INDEX SEMI 

dclvar_list chrtype SEMI 

dclvar_list inttype SEMI 

dclvar_list liketype SEMI 

extern dclvar_JList decttype SEMI 

dclvar_item 

dclvar_list COMMA dclvar_item 
simple_var 

simple_var dcl_subscr 
CHAR 

CHAR dcl_subscr 

SMALLINT 
INTEGER 

LIKE simple_var 
LP int_lit RP 
SET 

(empty) 

stmt_list stmt 

assign_stmt 
overlay-stmt 
clear stmt 
use stmt 
retum_stmt 
converse_stmt 
async_stmt 
cond_stmt 
do stmt 
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assign_stmt: 
over lay_stmt : 
clear_stmt: 
use stmt: 

i 

nest clause: 

~ i 

return_stmt : 
converse^ stmt : 
window_clause i 
async_stmt: 

i 
i 

attach detach: 

~ i 

refresh stmt 



view clause: 



field clause: 



I 



occur clause: 



beep-clause : 



i 



flash clause: 

" i 

cond stmt: 



do_idx_stmt 

MAP expr TO variable 

OVERLAY dat_item TO variable 

CLEAR variable 

USE MODULE MODULE_NAME 

USE RULE RULE_NAME nest clause 

(empty) 
NEST 

RETURN 

CONVERSE window_clause 
WINDOW WINDOW_NAME 

ASYNC attach_detach RULENAME VIA RULE 
RULENAME 

ASYNC ROUTE RULE RULE_NAME TO RULE 
RULE_NAME 

ASYNC refresh_stmt 

ATTACH 
DETACH 

REFRESH window_clause 

f ield_clause 

view_clause 

occur_clause 

beep_clause 

f lash_clause 

(empty) 

VIEW data_item 

(empty) clause 
FIELD data_item 

(empty) 

OCCUR data_item 

(empty) 
BEEP 

(empty) 
FLASH 

if_stmt 
case of-stmt 
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if -stmt : 

i 

case of stint: 

" "i 



caseof_var: 
case list: 

" i 

single_case: 
case lit list: 



do stmt : 

i 

do idx stmt: 



do clauses: 



from clause: 

_ ( 

to-clause: 

i 

by clause: 

i 

index clause: 

" i 

while clause: 

" i 

cond: 



simple cond: 

~ i 

rel op: 

~ i 



IF cond stmt-list ENDII 

IF cond stmt_list ELSE stmt_list ENDIF 

CASE_0F caseofvar caselist ENDCASE 
CASEOF caseofjvar case_list CASE OTHER 
stmt_list ENDCASE 

variable 

single case 

case_ list single_case 

CASE case_lit_list stmt_list 

lit 

set_const 
MINUS intlit 
MINUS dec_lit 
case_lit_list lit 
case_lit_list set_const 

DO stmt_list WHILE cond stmt list ENDDO 
DO stmt_list ENDDO 

DO do_clauses stmt_list while_clause ENDDO 

from_clause to_clause by_clause 
index_clause 

(empty) 
FROM expr 



TO expr 



BY expr 



INDEX variable 



WHILE cond stmt_list 

simple_cond 

LP cond Rp 

not cond %prec NOT 

cond AND cond %prec AND 

cond OR cond %prec OR 

expr rel_op expr 
expr INSET SETJNAME 

EQ 
NE 

nuro_rel_op 
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num_rel_op: 



LT 
LE 
GT 
GE 



variable: 



subscr_unit : 
item list: 



qual var list: 

" T 

dat item: 



set const: 
I 

lit: 



simple-var 

qual-id qual_yar_list 

simple_var subscr_unit 

qual_id qual_var_list subscr_unit 

LP item_list RP 

expr 

expr COMMA expr 

expr COMMA expr COMMA expr 

OF VIEWNAME 

qual_yar_JList OF VIEW_NAME 

variable 
lit 

set_const 
S YMBOL»_N AME 

SYMBOL_NAME IN SET_NAME 

char_lit 
int_lit 
dec lit 



APPENDIX C: RULES LANGUAGE SEMANTICS 
Identifiers 

Identifiers are used to name certain Language constructs, such as variables (for example, Fields and Views) and 
other Repository entities such as Rules and Components. 

A Field identifier must begin with an alphabetic charter. It is optionally followed by a sequence of one or more 
letters, digits, or underscores. No distinction is made between lower and upper case; therefore a_long_jdentifier and 
A_LONG JDENTIFIER name the same thing as far as the Rules Language is concerned. An identifier may not contain 
any embedded "while space" (blanks or tabs or new lines). 

You may use names for identifiers which are reserved words within the Cobol or C (or any other Language (such 
as SENTENCE OR SIZE). Note, however, that certain words have been reserved as keywords and for possible future 
extensions of the Rules Language (see Appendix A). Also, identifiers have restrictions upon their length, depending 
on what they name. These restrictions are listed in Figure 1 . 



Figure 1 Identifier Length Restrictions 


Maximum Identifier Type 


Number of Characters 


Field 


18 


View 


8 


Symbol 


18 


Set 


8 


Window 


8 


Rule 


7 


Component 


7 
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Appendix A contains a list of "reserved words" for the Rules Language. These identifiers may not be used to name 
any other Languages construct, such as Fields, Views, Rules, Components, etc. 

Operators and Delimiters 

The following characters have special significance to the Rules Language and are used as binary and unary op- 
erators. 



Figure 2 Binay and Unary Rules Language Operators 


Symbol 


Name 


Function 


( 


Left parenthesis 


Grouping; subscripts 


) 


Right parenthesis 






Equal symbol 


To form symbols for relational operators 


< 


Less than symbol 




> 


Greater than symbol 




<> 


Not equal symbol 


Test for inequality 


<= 


Less than or equal to symbol 


Test for less than or equal to 


>- 


Greater than or equal to symbol 


Test for greater than or equal to 




Minus symbol 


Negation 




Comma 


Separtation of list element and subscripts 




Semicolon 


Termination of declartion of local fields 


+ 


Addition 


For future use 




Multiplication 


• no 


/ 


Division 


■ an 


++ 


Union 




** 


Intersection 


■ MM 




Set difference 


■ an 


« 


Sub-Set 




» 


Superset 


• an 



Comments 

Comments are enclosed between "*<■ and "*>" as delimiters. Comments cannot be nested. There is no limit to 
the length of a comment 



40 



45 



*> This is an example of a comment <* 

*> This is <* *>another example <**> of a comment <* 

*> 

*lt is 

* prefect ion OK to 

* spread a comment 

* over more than 

* one line 

* and use * or < on their own 
<* 



50 Input past column 72 is treated as a comment (i.e., ignored). 

Data Items 



Data items are the variable and constants of the Rules Language. Figure 6-5 shows how these items are related 
ss to one another. 
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Data Item 

h Variable 
I— Field 
I View 



Constant 

L Uteral 



mr 

t 



Character Literal 
►Numeric Literal 



.Set Symbol 



Figure 3 Data item Hierarchy Table 



Variables 



Variables are defined using the View and Field HPS entities. Fields and Views are defined and described outside 
of the Language itself using the facilities of the Repository. Note that, with certain resctrictions, Fields and Views can 
be declared local to Rule Block by means of the DCL construct! 

Fields 



A Field is a variable which behaves like an atom; that is, it cannot be divided into smaller units. With the exception 
of a limited facility for declaring fields local to a Rule program, Fields are defined using the facilities of the HPS Re- 
pository. They are not defined within a Rule. Some examples of Fields and their types follow. 



FLD_1 


SMALLINT 


WORD_COUNT 


INTEGER 



In the example given above, FLD_1 is a two byte (signed) integer variable and WORD_COUNT is a four byte 
(signed) integer variable. 



FLD_2 


CHAR 


CUSIP_ DESCR 


CHAR (20) 



FLD_2 and CUS!P_DESCR are character Fields of lengths 1 and 20, respective I ty. 



CUST_BAL_AMT 



DECIML (15, 2) 



CUST_BAL_AMT is a "Dollars and Cents" variable with up to 1 5 digits precision, two of which are to the right side 
of an implied decimal point. DECIMAL (p.q) Fields are signed quantities. 



CASH_TXN_BAL_AMT PIC S9999V99 



CASH_TXN_BAL_AMT and CASH_TXN_CR_AMT are both numeric variables with up to 4+2 = 6 digits precision, 
two of which are to the right side of an implied (V= "virtual") decimal point. The S in the first example denotes an optional 
sign whereas in the declaration: 



CASH-TXN_CR_AMT 



PIC 9999V99 



CASH_TXN_CR_AMT cannot be negative. 
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TEMP_BUFFER VARCHAR (50) 



The constructs of the Rules Language do not distinguish TEMP_BUFFER from a CHAR (50) variable. Both CHAR 
(50) and VARCHAR (50) allocate 50 bytes of storage and In both cases anything that is moved into either of them will 
be left justified and padded to the right with spaces. A VARCHAR (n) variable keeps track of its "actual" length through 
the use of a separate length Field which is completely transparent to the Rules Language programmer 

The following table summaries the Field types which are supported within the HPS Rules Language and some of 
their properties: 



Type 


Representation (1) 


Char/Num 


Note 


Character 


CHAR (nn) 


Character 


(2) 


VarChar 


VARCHAR (nn) 


Character 


(3) 


2- Byte Integer 


SMALLINT 


Numeric 


(4) 


4- Byte Integer 


INTEGER 


Numeric 


(4) 


Decimal 


DECIMAL (p,q) 


Numeric 


(4) 


Signed Picture 


PIC S9999999v9999999 


Both 


(5,6) 




p times q times 







(1 ) " Representation" refers to the format of the DCL ... ENDDCL statement for a variable of that type. Note that the current release of HPS supports 
local declarations for data types CHARACTER, VARCHAR, and both SMALLINT and INTEGER Variables DECIMAL is not supported. See Section 
4 (Field Entity Types) for furthe Information on data types. 

(2) CHAR is the same as CHAR (1). 

(3) VARCHAR is the same as VARCHAR (1). 

(4) Integer, Decimal variables re signed variables. 

(5) Signed Picture varibles are signed, unsigned Picture variables are unsigned. 

(6) Picture variables are of a dual nature. They behave like numeric variables except in the following cases where there behave like CHAR (nn) 
variables: 

. When they are compared to Fields or Constants of the type CHAR or VARCHAR or to Views. 

. when they appear as the source of a MAP or OVERLAY statement the target of which is a Field of type Character or VARChar or a View. 



Views 



Data used by the CASE facility in the presented invention are organized into hierarchical structures. For example : 
35 a sub-View is the parent to a Field. 

For ease of documentation, Views are represented left-to-right in outline form rather than the graphical top-to- 
bottom method. The top-most (left-most) node is also referred to as the "01 -level View 1 (a COBOL and PL/1 convention). 

The following data structure has vw_1 as its 01 -level View. vw_1 consists of the child Views CG_VW_11, 
CG_VW_13, and CG_VW-10, and of the Fields CUSIP_DESCR, C UST_BAL_A MT, and CASH_TXN_BAL_AMT. The 
4 o sub-child View (also referred to as the child View or child of) CG_VW-1 3 of VWJ is bult from CG_DATE, SUB_VIEW, 
CG_BIT. The child SUB_VIEW of GC_VW_1 3 has the Fields CG VARCHAR and CG_CHAR, but no subordinate Views. 



45 



SO 
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VW_1, 

CG VW 11 



CG_DATE 
CG_VARCHAR 
CG_CHAR 
CG BIT 



CGJVW-13, 



CG_ DATE 
SUB_VIEW 

CGVARCHAR 
CG CHAR 
CG_BIT 

CUSIP_DESCR 
CUST_BAL_AMT 
CASH _TXN_BAL_AMT 

CG-VW-10 



CHAR 
VARCHAR 
CHAR 
CHAR 



CHAR 
(05), 
VARCHAR 
CHAR 
CHAR 



(08) 
(10) 
(10) 
(01) 



(08) 

(10) 
(10) 
(01) 



*>occurs 5 times<* 



CHAR (20) , 
DECIMAL (15,2) 
PIC S9999V99, 



SUB_VIEW (05) , *>occurs 

CG_VARCHAR VARCHAR (10) , 

CG_CHAR CHAR (10) , 

INT_RATE DECIMAL (7,7), 

CG_BIT CHAR (01), 



5 times<* 



Figure 5 Data structure From View 

The above View, VW_1 , illustrates many of the concepts underlying HPS data structures. 

Each of the sub- Views belonging to the above tree structure is itself a tree structure of which it becomes the 01 -level 
View. For example, CG_VW_10 defines a tree with CG_VW_1 0 as the top node, SUB_VIEW, INT_RATE and CG_BIT 
as its 2nd level leaves and nodes, and CG_VARCHR AND CG_CHAR as its 3rd level leaves. 

A view is uniquely determined within the Repository through the name of its 01 -level node. In other words, WV_1 
stands for the whole collection of all the Views and Fields in the figure. 

Virews and Fields can occur more than once within a true. But they are not allowed to form recursive constructs 
by referring to themselves, either directly or through a chain of itermediate child or parent Views. 

For example, CG_CHAR is a Field and SUB_VIEW is a View each appearing more than once within VW_1 . 

Note that in accordance with Paragraph 1, SUB_VIEW defines the same tree structure regardless of wether it 
appears as a child of CG_VW 10 or CG_VW_13. 



SUBJVIEW (05), 

CGJVARCHAR VARCHAR (10), 

CG-CHAR CHAR (10), 

Figure 6 sub -View Data structure 

The Field CG_CHAR that belongs to the View SUB_VIEW that belongs to the View CG_VW_10 can contain dif- 
ferent data from the Field CG_CHARthat belong to SUB_VIEW that belongs to CG_VW-1 3. In fact, they occupy different 
storage locations, furthermore, CG_CHAR appears elsewhere-it is also a Component of CG_VW_11 . How do you tell 
these instances apart within a Rules program? 

First, write the fully qualified name of the ambigously determined items (which may be either Fields or Views). The 
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fully qualified name begins with the name of the item at the lowest level (wich may be either a Field or a View) and 
works up to the top of the tree naming each of the Views (not Fields), sparating each ot the names with the reserved 
worf OF. (This naming convention is borrowed from COBOL and is different from the one used in C and PLA For 
example, in the case of CG_CHAR we have 



CG_CHR OR SUB__VIEW OF CG_VW_11 OF VW 1 

CG CHAR OF SUB__VIEW OF CGJVW-13 of VW_1, and 

CG_CHAR OF CG_VW_10 OF VW_1 

Figure 7 Fully Qualified Names 

The general notation is as follows: 

Let X be a Field or view which has a parent V1 which has apparent V2 ... and so on. 
Let Vn denote the top node ... 
Then, the fully qualified name of X is: 
Xof V1 OF V2 ...OF VN. 

These fully qualified names are sufficient to discriminate between the instances of CG_CHAR. In fact, they contain 
redundant information for the Rules code generator to discriminate between instances. To arrive at the necessary and 
sufficient information, simply delete the names of the Views which are common to the fully qualfied names. O f course, 
do not delete the name at the base of the upward path to the top level View. Applying this to the above example results in: 

CG_CHAR OF CG_VW_11 

CG_CHAR OF CG_VW-13, and 

CG_CHAR OF CG_VW_10 

Figure 8 Edited Qualfied Hemes 

This is the minimal information which the Rule code generator requires to discriminate between the instances of 
CG_CHAR. Furthermore, this is also the minimal information your eye would need to tell the instances apart with a 
glance at an outline of VW_1 . 

There is, however, on type of ambiguity which cannot be resolved with fully qualified names if partially qualified 
names are permitted. Consider the following View structure: 

VIEW10 

I— FIELD 1, *>first occurrence of FIELD1 <* 

VIEW1 , 

I j FIELD1 *>second occurrence of FIELD1 <* 
I — FIELD2, *>first occurrence of FIELD2 <* 

J— VIEW2 , 

FIELD2, *>first occurrence of FIELD2 <* 

FIGURE 9 AMBIGUOUS FIELD STRUCTURE 

VIEWO contains FIELD1 as an ambiguous reference because the only sensible choices for (partially qualified) 
names for the first occurence are either: 
FIELD1 
or 

FIELD1 OF VIEW 10, 

but both of them also make reference to the second occurence of FIELD 1 . Note in constrast that one can clearly make 
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a distinction between the contents of: 
FIELD2 OF VIEW1, 
and 

FIELD2 OF VIEW 2. 

5 

Subscripts 

The Rules Language supports views with subscripts (OCCURS Attribute of the View-View/HPS relationship). They 
are the counterpart of tables in COBOL and arrays in C or PL/1 . 
10 Assume that VW-2 is a View defined in the HPS Repository as follows: 

VW 2 



CG 



VW-11 


(8) 


*> occurs 


8 times <* 


CG DATE 


DATE 






CG VARCHAR 


VARCHAR 


(10), 




CG CHAR 


CHAR 


(10) , 




CG_BIT 


CHAR 


(10), 




VW 13 


(10) , 


*> occurs 


10 times <* 


CG— DATE 


DATE 






CG SUB VIEW 


(05) , 


*> occurs 


5 times <* 


CG -VARCHAR 


VARCHAR 


(10) , 




CG CHAR 


CHAR 


(10), 




CG_BIT 


CHAR 


(01) , 




VW 10 








CG VARCHAR 


VARCHAR 


(10) , 




CG CHAR 


CHAR 


(10) , 




CG_BIT 


CHAR 


(01), 




Figure 10 


Subscripted View 





35 

In each occurence of VW_2 there are 8 instances of CG_VW_1 1 (and all the Fields subordinate to it), 10 instances 
of CG_VW_1 3 (and all the Fields and View beneath it), and 5 instances of CG_SUB_VIEW subordinate to each of the 
10 instances of CG_VW_13. 

Note: An occurence clause is not a property of a View entity, but of the relationship (owns) created between one 
40 View and another. 

Using the example in Figure 10, CG)_CHAR) can be referred to as follows: 

1. CG_CHR OF CG_SUB_VIEW OF CG_VW_1 3 OF VW-2 (S1) 

2. CG_CHR OF CG_SUB_VIEW OF CG_VW_1 3 OF VW-2 (S1, S2) 

45 3. CG_CHR OF CG_SUB_VIEW OF CG_VW_1 3 OF VW-2 (SI, S2. S3) 

where S1, S2, S3 denote the subscripts of VW-2, CG-VW-13 and CG_SUB_VIEW respectively. Note that in conven- 
tional terms, number 1 above corresponds to a two-dimensional array, number 2 above to a one dimensional array, 
and number 3 above refers to a single field item. 
so No View which is used in the Rules Language is allowed to have more than three (3) occurs Attributates in any of 

its qualification paths. Also note that the subscripts are written such that the leftmost subscript correspondes to the 
topmost View with multiple occurences along the path from X to Vn. 

A view can be nested up to 20 levels deep. In other words, given that the level number increase as follows: 
01 03 05 07 

ss the highest level number supported is 39. 
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Constants 

Constants appear in the Rules Language in two manifestations: 

literals, and 
Set symbols. 



10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



They can represent: 

characters, such as "New York City," or 

(signed) integer numbers, such as 123 or 1234567, or 

(signed) decimal numbers such as 123.45 or 1234.50. 

Numeric Literals 

There are two types of numeric literals: integer numbers and decimal numbers. An integer is a sequence of one 
or more digits. A decimal number is a sequence ofone or more digits followed by a decimal point which may be followed 
by zero ormore digits. A negative number is expressed by preceding the digits with a minus sign. 

For example, 0 and 123 are integers. 123.0, -7734.33 and 123.456 are valid decimal constants as is 0.456. 

These literals have restrictions upon the number of digits they contain depending upon their type (integer or dec- 
imal). Integers consist of up to 15 digits while decimals contain up to 16 digits (15 + 1 for the decimal point). Positive 
numbers may not be preceded by a plus sign but negative quantities must be preceded by a minus sign. 

Character Literals 

A character literal is a '(single quote) followed by zero to 50 character (other than ') folbwed by' a'. The following 
are valid character literals. 

This is a valid character constant' 
'ZYZZY and PLUGH are magic words' 
The last example is a null string. If it is necessary to include a single quote character in the literal itself, the usual 
dodge of using two consecutive single quotes may be employed. For example, 
'Mike' 's computer is broken.' 
is 

Mike's computer is broken 
Note that single quote must be used. Double quotes are not valid. 

Sets and Symbols 

A set is a collection of constant value data items. All constants are of the same data type. For example, all ot them 
will be CHAR(6) or all of them will be SMALLINT Because of this property we can refer to the data type of a Set. The 
constants of a Set behave like Fields rather than views in the following sense: 

They cannot be broken down into lower levels and 

they cannot have an Occurs clause. 

In addition, the whole Set does not have an Occurs clause. 

Example: 



SET 


MONTHSET 


SMALLINT, 




JAN 


VALUE 1, 




FEB 


VALUE 2. 




MAR 


VALUE 3, 




APR ! 


VALUE 4, 




MAY 


VALUE 5, 




JUN 


VALUE 6, 




JUL 


VALUE 7. 
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(continued) 



SET 


MONTHSET 


SMALLINT, 




AUG 


VALUE 8, 




SEP 


VALUE 9, 




OCT 


VALUE 10, 




NOV 


VALUE 11, 




DEC 


VALUE 12; 



10 

The example defines a Set called MONTHSET which is composed of a collection o1 twelve constants which rep- 
resent the twelve months of a year. Their symbols are JAN, FEB. DEC and their associated values are integer 
literals 1, 2, ... 12. 

MONTHSET is of the type SMALLINT which means the format of the values is SMALLINT There cannt be a VALUE 
is 3.21 nor VALUE "NOT AN SMALLINT' nor VALUE 1 234565. This last example is invalid becuase an SMALLINT cannot 
exceed the number 32767). 

This example will be used for turther illustration of the Set concepts. 

Each of the constants of a set possesses an identifier called a SYMBOL, and a value. Tne SYMBOL is a vehicle 
for referencing the underlying value. A Set symbol can be used in the same way as a Field. The principal difference 
20 is that the value of a Set symbol is constant and can never be altered through a Rules statement, whereas the value 
of a Field can be changed; for example, by clearing it or making it the target of a MAP or OVERLAY Statement. 
Assume SYMXXX is a symbol belonging to a Set SETYYY. It can be referenced in either of the following ways: 

SYMXXX 
SYMXXX IN SETYYY 

25 The IN keyword was chosen instead of the OF keyword to avoid overloading the meaning of the latter with too 

many different uses. SYMXXX must be qualified with its Set if SYMXX is used, within the Rule, either as the symbol 
of another Set or as a Field name or as a View name. 
Referring back to the MONTHSET example: 
MAR 

30 MARIN MONTHSET 

3 

note that each have exactly the same meaning, namely the number three 

MAT FEB IN MONTHSET TO XXXVAR OF YYYVIEW 

has the effect of moving the value 2 into the Field XXXVAR which is, hopefully, properly declared somewhere within 
35 the Rule or its bind file as a numeric sub-Field of the View YYYVIEW. 

Within a Set, there cannot be two or more symbols with the same symbolName. Note though that a Set can possess 
several symbols with one and the same value! 

Other Identifiers 

40 

Besides data items, the following entities are used within a Rule: 

Rule Name 
Component Name 
45 Window Name 

Set Name 

They will be described in detail during the discussion of the excutable statements where they occur. 
so Local Dec (art ions 

On occasion, it is convenient to have variables local to a Rule program. A variable used as the indexing variable 
of an indexed DO is a good example of such a variable. The DCL ... ENDDCL statement permits the declaration of 
local variables. 

55 

Syntax 

The DCL ... ENDDCL statement has the form: 
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DCL 

declaration ; [declartion ; 
ENDDCL 



where declaration is either 



[identifier [ (S) ] 
[, identifier [ (S) ] , declare_type 

or 

EXTERN identifier 

[ , identifier, ... ] SET 



"(s)' is a subscript (integer constant in parenthesis). 
Declare type as either of the following: 

SMALLINT 

INTEGER 

CHAR 

LIKE already_declared_item 

Note: Declaratins of the type EXTERN cannot be subscripted, "identifier" must start with an alphabetic character. 
The following characters are either alphabetic.numeric, or underscores. already_declared_item refers to an 
item which is alredy known to the Rule either through preparation from the HPS Repository or through a 
previous local declaration. 

An example follows: 



DCL 

I, J,K,L r M,NM INTEGER; 

SSN CHAR (11); 

TEMP_ID CHAR ( # § ) ; 

TEMP_VIEW LIKE RTAXCMPI (5); 
ENDDCL 



Figure 10 Example DCL. ENDDCL STATEMENT 

Note that it is not possible to directly define a View within a DCL ... ENDCL statement. It is possible to do so 
indirectlywith the LIKE clause. In the above example, TEMP_VIEW is a temporary local View with nearly the same 
structure as RTAXCMPI. The only difference is that the 01 -level name is TEMP_VIEW rather than RTAXCMPI and the 
TEMP_VJEW OCCURS 5 times. 

APPENDIX D: Executable Statements of Rules Language 
Assignment of Value 

Three types of statements alter the value of data contained in Fields and Views: MAP, CLEAR, and OVERLAY. 
The syntax and semantics of each will be described in turn. 
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MAP STATEMENT 
Syntax 

The syntax of the MAP statement is: 
MAP data_item TO variable, 

where data_item is a constant, a Field name, or a View name and variable is either a Field name or a View name. 
Recall that the Field or View names must be unambiguously qualified and these names may include subscripts. 
Some examples follows: 



MAP 'Syntax' TO CG_CHAR OF CG_VW_11 

MAP CG CHAR OF CG_VW_11 TO CG_CHAR OF SUB_VIEW OF 
CG_VW_13 (3) 

MAP 23400.00 TO CUST_BAL_AMT 

Figure 1 Example Map Statements 

Semantics 

The results of mapping A to B, as an example, can vary greatly depending on the data types of A and B. One can 
see how those assigments work by studying the following matrix built according to the following principle: 

The possible sources (A) for a MAP statement constitute the rows of the matrix and the possible destinations (B) 
constitute its columns. The syntatic correctness or result of the MAP opertionis given at the intersection of the row and 
column. The numbers in parenthesis refer to the numbered paragraphs immediately following the matrix. VW(5) and 
WV(8) are two Views-both with the multiple occurences but one with fewer (5) and the other with more (8). 
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Source 
(A) 

View 



Field 
Num lit 

Char lit 

Set 

Symbol 

VW(5) 

VW(8) 



(B) 

View 

"OK 
(1) 

ERROR 
ERROR 

ERROR 



ERROR 
(2) 

ERROR 



Field 
ERROR 

(4) 
(6) 

(5) 

ERROR 

(6) 



Destination 
Const 
ERROR 

ERROR 
ERROR 



WARNING ERROR 



ERROR 



WARNING 
(3) 



ERROR 



ERROR 



ERROR 



VW(5) 

WARNING 
(3) 

ERROR 

ERROR 



ERROR ERROR 



ERROR 



ERROR ERROR 



OK 



WARNING 
(3) 



VW(8) 

WARNING 
(3) 

ERROR 

ERROR 

ERROR 

ERROR 

ERROR 

WARNING 

OK 



Figure 2 The Map Operation 



(1) Mapping a View to a View means mapping all sub-Views and/or 
Fields with corresponding names which are subordinate to 
the source View and the destination View. For example, 
assume we have: 



VIEWl 

ABC 

DEF occurs (50) 

OPQ 

XXX 

BBB 

XXY 

XY2 



VIEW_2 

OPQ 
ABC 

DEF occurs (9) 
BBB 

zzz 



where the specifics of the sub-Views and the Fields of VIEW1 and 
VIEW2 do not matter. Then, MAP VIEW_1 TO VIEW_2 will have the 
folowing effect: 



ABC OF VIEW 1 
OPQ of VIEW_1 
BBB OF VIEW 1 
DEF OF VIEW_1 (1) 
DEF OF VIEW_1 (2) 



is moved into 
is moved into 
is moved into 
is moved into 
is moved into 



ABC OF VIEW 2 
OPQ OF VIEWJ 
BBB OF VIEW_2 
DEF OF VIEW_2 (1) 
DEF OF VIEW2 (2) 
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DEF OF VIEW 1 (5) is moved into DEF OF VIEW_2 (5) 

Nothing is mapped from xxx, xxy, xyz to anywhere because 
VIEW 2 does not have children with those names directly 
below it. Nothing is mapped int zzz because VIEWW __l 
does not have a child with this name directly below it. 

Assume that xxx and zzz are themselves Views which are 
built as follows: 

xxx zzz 
FLD1 FLD1 

FLD2 FLD3 

FLD3 FLD5 



FLD1 OF xxx OF VIEW_l is not moved into FLD1 OF zzz OF 
VIEW 2 



FLD3 OF xxx OF VIEW_1 is not moved into FLD3 OF zzz OF 
VIEW_2 

The reason is that only the children directly below the 
source (= VIEW_1) and the target (« VIEW_2) of the MAP 
statement are eligible candidates for matching names. 
That is, the codegenerator only look one level down when 
performing comparisons of View structures. 

A set isneither a constant, nor a variable, and 
absolutely nothing can be mapped from or to a Set. 

Assume tht A occurs nn times and B occurs mm times and 
that min denotes the smaller one of mm and nn. Then: 



MAP A TO B 



means exactly the same as the following Rule fragment: 

DO FROM 1 TO min INDEX IX 

MAP A(IX) to B(IX) 

ENDDO 



If either A occurs multiple times and B does not or A 
occurs once and B multiple times, then MAP A TO B is 
equivalent to eithr 
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MAP A(l) TO B 

or 

MAP A TO B(l) 

(4) See the Field-to-Field MAP in Figure 2. A cource 
literal of type INTEGER or DECIMAL behaves the same as a 
variable of that type. 

(5) See the Field-to-Field MAP in Figure 2. A source 
literal of the form 'ABCDEFGH' behave the same as a 
variable of type CHAR (8) . 

(6) See the Field-to-Field MAP in Figure 2. A source which 
is a symbol belonging to a Set of a given type behaves 
in the same way as a variable of the same type. 



Mapping of VARCHAR Fields 

The following describes how MAP statements operate with variables ot type VARCHAR. 

The major difference between variables of type VARCHAR (nn) and those of type CHAR (nn) is due to the fact 
that VARCHAR (nn) variables have an associated lenth Field, names xxx_LEN for a VARCHAR variable xxx. xxx_LEN 
contains the 'actual lenth' of xxx while nn is the "maximal length" of xxx. 

Assume that B is a variable of type VARCHAR with lenth B_LEN and that A is a variable, a literal, a symbol of type 
VARCHAR, or of type "char." B_LEN is determined from the length of A in a MAP A to B statement as follows. 
If length of a <=maximum length of B, then: 
B_LEN length of A 
contents of B = contents of A padded with spaces to the right 
If length of A >maximum length of B, then: 
B_LEN =maximal length of B 
contents of B=first "max length of B" characters of A 
Examples of the Use of VARCHAR Variables 
Assume the following: 



CHAR_VAR1 
CHAR_VAR2 
VARCH_VAR1 
VARCH VAR1 



of type CHAR (10) 
of type CHAR (20) 
of type VARCHAR (15) 
of type VARCHAR (20) 



Assume also that we have a Rule which consists of the following MAP statements: 



1. 


Map 'ABC ' 


TO CHAR_VAR_1 


2. 


MAP '** MY LENGTH IS 20 **' 


TO CHAR_VAR_2 


3. 


MAP *ABC 1 


TO VARCH_VAR_1 


4. 


MAP CHAR_VAR_1 


TO VARCH_VAR_1 


5. 


MAP CHAR_VAR_2 


TO VARCH_VAR_1 


6. 


MAP CHAR_VAR-2 


TO VARCH_VAR_2 


7. 


MAP VARCH_VAR_2 


TO VARCH_VAR_2 


8. 


MAP VARCH_VAR_1 


TO VARCH_VAR_2 



The following results will occur in teh VARCHAR variables 



#1 and 2 Nothing has yet been assigned to VARC H-VAR_1 _LEN and VARC H_VAR_2_LE N 
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(continued) 



-WO 


\/AD/^l_l WAD ■I 

VAHO ri_ VAH_ 1 . 


_LtN 


= 5 = 


length of ABC 


#4 


VARCH_VAR_1. 


_LEN 


= 10 


= length of CHAR_VAR_1, 


#5 


VARCH_VAR_1. 
LENGTH IS' 


_LEN 


= 15 


= length of CHAR_VAR_1 , contents ol VARCH_VAR_1 will be ' ** MY 


#6 


VARCH_VAR_1. 
LENGTH IS* 20' 


_LEN 


= 20 


= length of CHAR_VAR_1 , contents of VARCH_VAR_1 will be ' ** MY 


#7 


VARCH_VAR_1. 
LENGTH IS' 


_LEN 


= 15 


= length ol VARCH_VAR_1 , contents of VARCH_VAR_1 will be ■ ** MY 


#8 


VARCH_VAR_1_ 
IS' 


_LEN 


= 15: 


= length of VAR_VAR_1 , contents of VARCH_VAR_1 will be 1 ** MY LENGTH 



CLEAR Statement 



The CLEAR statement sets numeric Fields to zero and character Fields to blank. 
Syntax 

The CLEAR statement has the form: 
CLEAR variable 

where "variable" is fully or partially qualified name of either a view or a Field. If the variable being cleared has subscripts, 
that is, multiple occurences of any of its Views or sub-Views, then subscripts may also appear. For example, 
CLEAR VWJ 

will zero all the numeric Fields of VWJ and blank the character Fields. Recall that numeric Fields include INTEGER 
(n), DECIMAL (p, q). and Fields desribed with PIC elements S,9,and V. Character Fields include CHAR (n_, VARCHAR 
(n). 

Semantics 

A Field of underlying type "Character" (not including PICs) is set to blanks. A Field of underlying type "Numeric" 
(including decimals and PICs) is set to zero. 
A View V, say, is treated as follows: 

(1) Assume that V owns Fields only but no View. Then each one of those Fields is Set to spaces or to zero, 
depending on wether its underlying type is "Character" or "Numeric." If V is a View that is subscripted (the corre- 
sponding OCCURS clauses could possible be specified on a higher level than that of V), then clearing V means 
the same as clearing each v(S1) or v(S1, S2) or v (S1, S2 S3). Here S1, S2 and S3 denote the Subscripts of V 
and it depends on the number of OCCURS above and including the level of V, regardless of wether V is subscripted 
once, twice, or three times. 

(2) If V has one or more views V1 , V2, as children, then treat V as follows: Clear the Fields which are children 
of V, just as was outlined above. Then check each V1, V2 to determine wether or not it also contains Fields as 
children and, if so, treat them according to (1) above. Otherwise examine each sub-View. 

The net result of the above algorithm is as follows. Any View is ultimately partioned into a Set of Fields. Each of 
those Fields is set to spaces or to zero, depending on wether its underlying type is "Character" or "Numeric". 

OVERLAY Statement 

This statement is used to replace ("overlay") one structure in storage with the content of another. 
Syntax 

The OVERLAY statement has the form 
OVRLAY data item TO variable 
where data item is a constant, Field, or View and variable is either the name of a View or a Field. 
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Semantics 



As in the case of the MAP statement, the effect of OVERLAY is complex and depends upon the types of the source 
and destination variables. 



Source 
(A) 

View 
Field 
Num lit 
Char lit 
Set 

Symbol 
VW(5) 

VW(8) 



View 

"OK 
(1) 

(4) 

ERROR 
(5) 



ERROR 
(2) 

(10) 



Field 

ERROR 
ERROR 
ERROR 
ERROR 
ERROR 



Destination 



Const 



VW(5) 



VW(8) 



ERROR 



ERROR 



ERROR 



ERROR 



ERROR 



ERROR 



WARNING WARNING ERROR 
O) (3) 



WARNING WARNING ERROR 
(3) (3) 



WARNING 
(3) 

WARNING 

(3) 

ERROR 



ERROR 
ERROR 
ERROR 
OK 



WARNING 
(3) 



WARNING 
(3) 

WARNING 
(3) 

ERROR 



ERROR 
ERROR 
ERROR 



WARNING 
(3) 



OK 



Figure 3 The Overlay Operation 



(la) The Overlay statement operates in a fundamentally 

different way from the MAP statement. If the source (S) 
and destination (D) variables are both Views, then 
OVERLAY S to D has the same effect as a straight COBOL 
Move. both S and D are treated as if they were of type 
Character. Let nn be the smaller of length (S) and 
length (D). Then the above statement will simply move 
the left most nn characters of s into the leftmost nn 
characters of D, padding the excess bytes of D with 
spaces if length (D) is greater than length (S) . 

(lb) if A is a View and B is a Field, then OVERLAY A TO B is 
OK as long as B is of type "character" (which is the 
case for PIC Field) . 
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(lc) Either A or B or both must be a View. Nothing can ever 
be OVERLAYED to a Constant. 

(2) A Set is neither a constant, nor a variable, and 
absolutely nothing can be OVERLAYed from or to a Set. 

(3) Assume that A occurs nn times and B occurs mm times and 
that min denotes the smaller one of mm and nn. then 

OVERLAY A to B 

means exactly the same as the following Rule fragment: 

DO FROM 1 TO min INDEX IX 

OVERLAY A (IX) to B(IX) 

ENDO 

If either A occurs multiple times and B does not or A 
occurs once and B multiple times, then OVERLAY A TO B is 
egualent to either 

OVERLAY A(l) TO B 

or 

OVERLAY A TO B(l) 

(4) It is permitted to OVERLAY a Field with a View or vice 
versa, as long as the Field is of type "Character." The 
reason is that Views themselves re considered to be of 
type "Character" (COBOL convention) . 

(5) It is permitted to OVERLAY a constant (literal or 
symbol) to a View, as long as the constant is of type 
"Character." 



APPENDIX E: Flow of Control With a Rule 

The Rules Language employs the usual flow of control constructs: IF and IF ... ELSE for conditions execution, 
CASEOF lor selection of one of several altemtives.and DO.. .WHILE for control of repetitive loops. 

Conditions 

A condition is a mix of data items, relational operators, Boolean operators, and parentheses. A data item includes 
character, integer, and decimal constants, Fields, and Views, the relational and Boolean operators are: 



Figure 1 Relational and Boolean Operators 


Operator 


Meaning 




Equal to 


<> 


I Not equal to 


< 


Less than 


<= 


Less than or equal to 


> 


Greater than 


>= 


Greatern that or equal to 


INSET 


Is a member of 
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(continued) 



Figure 1 Relational and Boolean Operators 


Operator 


Meaning 


AND 
OR 
NOT 


Conjunction 
Inclusive disjunction 
Negation 



A condition is either a single relational condition (henceforth called a "simple condition") or two or more conditions 
connected with the Boolean operators. A simple condition has the form 
data item relational operator data item 
Some examples are : 

CUST_BAL_AMT < 1000 

GROSS J=>AY OF RTAXCMPI >= FICA_CUTOFF 

CUSTOMERJD <> '11 34-4' 

SSN OF RTAXCMPO = '360-32-2528' 

12 INSET MONTH J3F_YEARS 



The Rules Language enforces data-type checking; comparisons can only be made between data items of like 
type-numeric with numeric and character with character. All of comparisons o1 magnitude are available with numeric 
data but only tests for equality (=) and inequality (<>) are permitted with character data. 
25 Each simple condition results in a value of either TRUE of FALSE, two of these values can be combined with the 

Boolean operators AND and OR and the sense of one of them can be reversed with NOT 

For example, 

CUSTOMERJD <> '1134-4' AND GROSS_PAY >= FICAJJMIT 
is TRUE if both CUSTOMERJD is not equal to 1123-4' and GROSS_PAY is greater than or equal to FICAJJMIT; 
30 otherwise the condition is FALSE. It is assumed that CUSTOMERJD is either CHAR, VARCHAR, or a View and 
GROSS_PAY AND FICAJJMIT are INTEGER, DECIMAL, or desribed with numeric PIC elements. Further, for this 
condition to make sense, the relational operators <> and >= must be applied before the two resulting values are ANDed. 
This implies all the opertors have hierearchy of precedence. The usual hierarchy is used, and it is given in the following 
table. 

35 
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Figure 2 Precedence - Relational a 


nd Boolean Operators 


Operator 


Precedence 


INSET 


Highest 


=, <>, <, <=, >, >- 




NOT 




AND 




OR 


Lowest 



45 

The concept of operator precedence is well known from the everyday usage of arithmetic calculations, where 
multiplication and division are executed before addition and substraction. In the same way, a test for inequality is 
executed before two conditions are ANDed, which itself will be done before my conditions will be ORed. 

parentheses may be used to override the operator precedence. For example, 
so NOT X = Y or C >D is equivalent to (NOT X+Y) or (C>D), 

which itself is equivalent to X <> Y or C >D. 
however, 

NOT (X = Y or C >D) is equivalent to X <> Y AND C <= D (because it is true in general that NOT (X OR Y) is the 
same as (NOT X) AND (NOT Y). 
55 The removal of the NOT shows that the two conditions are quite different. So long as the comparisons are legitmate 

the conditions can become arbitraly complex. For example 

(( PAY > LIMIT or BONUS >= MAX) AND ID <>'112A-3X') OR 

ID=" 
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is syntactically correct. 
INSET Statement 

5 A Set can be tested to determine whether a given variable or constant appears as a value within the Set. 

Let X be a data item whose data type is compatible to (even though not necessarily identical to) data-type-of-the- 

Set. 

Then 

X INSET SETJSJAME 

io is a condition which evaluates to either TRUE or FALSE depending on wether or not at least one of value in SET_N AME 
matches the value of X. 

It is not permetted to check whether a numeric data item is INSET a Set of type character and vice versa. Note 
that PICTURE Fields and/or set symbols an be compared to both character and numeric data items. Note also that a 
View is considered, for comparison purposes, to behave like a character variable. 
is Assume the following delcarations: 



CHRVAR1 CHAR (10) , 

CHRVAR2 CHAR (6) 

20 SHRTINT SMALLINT ; 

LONG I NT INTEGER; 



SET MONTHS ET SMALLINT, 
JAN VALUE 1, 

25 FEB VALUE 1, 



30 



35 



DEC 

SET NAMES ET 
AL 
JAN 
JAMES 
JIM 
JON 
BOB 



VALUE 12; 

INTERGER 

VALUE 4 
VALUE 12345 
VALUE 1234567, 
VALUE 12345677, 
VALUE 123456788 
VALUE 123456789; 



The following expressions are valied: 



45 



JAN IN MONTHSET INSET NAMESET 


*>Results=FALSE<* 


AL INSET NAMESET 


*>Results=TRUE<* 


AL <= JAN IN MONTHSET 


*>Resutts=FALSE< # 


AL <= JAN IN NAMESET 


*>Resufts=TRUE<* 


AL <= AL IN NAMESET 


*>Results=TRUE<* 


AL <= AL NAMESET 


*>Results=FALSE<* 


SHRTINT INSET NAMESET 




LONGINT INSET MONTHSET 





Of course, nothing can be said at code generation time about the results of the last two expressions because they 
involve variables. It might have come as a surprize to the reader that: 

JAN IN NAMESET INSET MONTHSET evaluates to FALSE? 

Comparison of like types is rigidly enforced. Comparisons between numeric data and non-numeric are always 
erros. The following table gives conditions arising between the comparison ol two character types and or twonumeric 



42 




EP0 502 975 B1 



types. The significane of note (1 ), however, varies according to the types being compared. 





Figure 3 Character and Numerican Comparison Error Conditions 


5 


First 


Second 






Literal 


Set symbol 


Variable 


10 


Literal 
Set Symbol 
Variable 


Error 
Warning 
(1) 


Warning 
Warning 
(1) 


(1) 
(1) 
OK 


15 


(1) Comparing a character constant to acharacter variable is permitted so long as the length of the constant is 
less than or equal to the maximal length ot the variable. Otherwise a syntax error is generated. 

It is an error to compare a large (in absolute value) numericliteral with a variable which is 'toosmaM" to acco- 
modate a value that large. For example, an SAMLLI NT Field can accommodate values ranging from -32,768 to 
+32,767. Let SMALLJNT be an SMALLINT Field. The following comprisn is not permitted by the Rule code 
generators: 

SMALLJNT > 1000000 



Even more subtle errors are detected. Let POS-NUMBER be a decimal number described by the picture "PIC 
9999/V99" in the HPS Repository. Then the next example conditionis also not permiteed: 
POS_NUMBER < 0 

this is an error because POS-NUMBER does not have a leasing sign picture element S. 



Not: On the comparison of character type items assume that X= 'ABC* and Y = 'ABC and Z = 'ABC '. Then X and 
2S y and Z are all equivalent as far as testing them for equality is concerned. 

In other words, the complex condition X = Y and Y=Z and X=Z evaluates to TRUE. In addition, note that the 
ASCII collating sequence and not the EBCDIC collating sequence applies for relative comparison. Given the 
above definition, the condition 
X <= '1BC* 

30 yields TRUE because the ASCII value of V is49, whereas the ASCII vlue of 'A' is 65. 

IF STATEMENT 

IF..., IF ... ELSE (Conditional Execution) 

35 

Syntax 

The IF statement has the general form 

40 

IF condition 
statement . . „ 

[ELSE 

45 

statement . . . ) 

ENDIF 

50 where "condition" is a logical expression which may be either TRUE or FALSE. "Statement" represents a Rules Lan- 
guage statement, and means taht the immediately preceding item may be repeated, and [ ] implies, and [ ] implies 
that what iscontained within [ and ] is optional. A then is not allowed in the IF statement. 

CASEOF Statement 

55 

CASE (Selection of One of Several Alternatives) 

The CASEOF statement selects one of several alternative execution paths on the basis of the value of a character 
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or numeric Field. It is equivalent in meaning to several nested IF ... ELSE STATEMENTS. 
Syntax 

5 The CASEOF statement has the following form: 

CASEOF VARIABLE 
10 CASE literal [ literal ] ... 

[ statement ... ] 
[ CASE literal [ literal ] ... 

15 

[ statement ... ] ] ... 
[ CASE OTHER 
20 [ statement . . . ] ] 

ENDCASE 

The notation used here to express the syntax is more complex than that used for the IF statement. Square brackets 
25 ([ and ]) enclose items that may be omitted. Ellipses (...) indicate that the immediately preceding item may be repeated. 
Putting these two conventions together means that [ statement ... ] is equivalent to no statements, anything within [ 
and ] is optional) or one statement, two statements (...following statement means that it can be repeated), three state- 
ments, and so on. 

30 Semantics 

The CASEOF statements is a shorter way of expressing the same flow of control using nested IF ... ELSE state- 
ments. The variable is compared to the list of literals folbwing the first CASE reserved word. !f it is equal to any of 
them then the statements following the first CASE are executed up to but not including the second CASE; flow of control 
35 then passes to the statements following the ENDCASE. 

If the variable is not equal to any of the literals following the first CASE clause, then it is compared to the literals 
following the second CASE. If the variable is equal to any of them, then the statements following the second CASE 
clause up to, but not including the third CASE are performed; flow then passes to the statements following the END- 
CASE. 

40 This proess is repeated until all ol the CASE clauses have been exhausted. The statements following the optional 

CASE OTHER are performed only if the variable in the CASEOF clause is not euqal to any of the leterals listed in the 
CASE clauses. 

the literals appearing in the various CASE clauses must appear only once. A literal appearing in one of the CASE 
clauses cannot be repeated in another. 
45 The following shows a skeleton example of the use of a CASEOF construct along with the semantically identical 

translation to a Set of nested IF statements. 
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CASE OF TRANS_CODE 

CASE 'A' 'C 

statement 1 
statement 2 

CASE 'M' 'R' 'D' 

statement 3 

CASE 'X' 

statement 4 
statement 5 

CASE OTHER 

statement 6 

ENDCASE 

The IF statement equivalent of the above follows: 

IF TRANS_CODE = 'A' OR TRANS_CODE = 'C 

statement 1 
statement 2 

ELSE 

IF TRANS_CODE = 'M' OR TRANS CODE - 'R' OR TRANS- 
CODE = 'U M ~ 

statement 3 

ELSE 

IF TRANS_CODE « 'X' 

statement 4 
statement 5 

ELSE 

statement 6 

ENDIF 
ENDIF 

ENDIF 

Observe that the CASEOF statement implicity uses tests for equality between a varible (Field or View) and 
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constant. The type checking enforced with the IF statement is also enforced here. Constants appearing in the CASE 
clauses must have the same type as the variable appearing on the CASEOF clause. 

DO Statement 

The DO ... ENDDO construct provides control of repetitive loops and there are two varieties-one with an explicit 
loop-counting mechanism and one without. 

Syntax 

The form of the DO ... ENDO loop control structure is as follows: 

DO 

[ statement ... ] 

WHILE condition 
[statement ... ] 

UNDDO 

The form with the explicit loop-counting mechanism is: 



DO [FROM integer data item] 
[ TO integer data item] 
[ BY integer data item] 
[ INDEX integer variable] 

[ statement ... ] 

[ WHILE condition ] 

[ statement . . • ] 

ENDDO 



The "condition" appearing in the WHILE clause is the same type of condition as described above in the section of 
the IF statement. An "integer variable" is either a Field which is defined as INTEGER in the Repository or is a DCL 
local to the Rule. An "integer data item" is a liteal, a Set constant, or the name of a Field defined as INTEGER, if needed 
to resolve any ambiguity, partial qualification and subscripting may be required with Field names. 

Some examples of DO-loops follows: 
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DO 

WHILE FICA OF RTAXCMPI <FICA_MAX_IN PARAMETERS 
statement 1 
statements 



ENDDO 

10 DO 

statement 1 
statement2 

• • • 

WHILE TOTAL_AMT > TOTAL_LIMIT 
t5 ENDDO 

DO TO LOOP_END BY STEP INDEX COUNTER OF RXYZZYI 
statementl 
statement2 

20 

ENDDO 

DO FROM LEVEL OF RSTATUSI 
statementl 
statement2 

WHILE CODES (LEVEL) <> TERM_CODE IN VALID_CODES 
statement3 

• • • 

ENDDO 

30 

Semantics 

For the first type of DO construct-without the explicit counting machanism-the statements between DO and END- 
35 DO are repeated in order of appearance while the condition in the WHILE clause is TRUE. When the condition becomes 

FALSE, control passes from the WHILE clause to the statement following the ENDDO. Note that the while clause may 

appear at the top of the loop, at the botton of the loop, or anywhere in the middle. 

In the second type of DO, default values are supplied for any of the missing clauses (FROM, TO, BY). If FROM is 

omitted, the loop count begins at 1 ; if TO is omitted, the count limits is set to 32,767; if BY is omitted, the loop increment 
40 is set to 1. Note that the INDEX clause need not appear. However, at least one FROM, TO, BY, or INDEX must be 

given for the DO to be recognized as in indexed DO. Also, IN, FROM, TO, and BY values need not be integer constant; 

integer Fields are also permitted. Finally, a WHILE condition may also be included with an indexed DO and it may 

appear anywhere within the loop. 

45 APPENDIX F: Transfer of Control Between Rules 

A Rule may invoke another Rule or a Component. A Component may invoke another Component, but not a Rule. 
USE Statement 

50 

Syntax 

The USE RULE statement invokes another Rule and the USE MODULE statement invokes a component. They 
are similar in appearance: 
S5 USE RULE rule-name [ NEST ] 

USE MODULE components_name 
where rule_name is the name of a Rule and component_name is the name of a Component known to the Repository. 
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Semantics 

Upon execution o1 USE RULE or USE MODULE, control is passed to the named Rule or Component. Unlike 
programming languages, the USE statement itseH does not have associated with it any of the parameters to be passed 
s to the invoked Rule or Component. 

The Rule Language requires that the input View and the output View of a Rule be defined in the Repository not 
within the program per se. Furthermore, the input View to be passed to an invoked Rule and the Output View to be 
retrieved from it must also be recorded in the Repository for both the invoking and invoked Rules. 

10 Semantic Checks For Target Environments 

In a system having the architecture of an IBM mainframe, an IBM mini computer supporting Stratus VOS operating 
system, and PC work stations, only a PC-base may invoke a Rule belonging to a different target environment. The 
code generator will flag an error if one should attempt to USE a Stratus Rule or a PC Rule from a mainframe Rule or 
is if one should attempt to USE a mainframe Rule or a PC Rule from a Stratus-based Rule. Note also that a Rule can 
only USE a Component which is targeted for its own environment. 

Semantic Checks For NEST Clause 

20 The Nest option indicates that all Windows invoked by this Rule and its calling Rules will come up in 'pop up" 

mode; i.e., it will be displayed over the screen that was conversed prior to this one. NEST can be used only if: 

the Target Environment of the USEing Rule is PC, or 

25 . The Target Environment of the used Rule is PC. 

However, Rules on other machines cannot invoke a PC-based Rule (except indirectly through the ASYNC facility). 

RETURN Statement 

30 

An invoked Rule program executes the RETURN statement to transfer control back to the invoking Rule. The 
RETURN statement may be laced anywhere in a program. The Rules Language code generator places an implicit 
RETURN at the end of each Rule program. 

35 Transfer of Data Between Rules 

As was mentionned in the previous section, Rules may have at most one Input View and one Output View defined 
in the Repository. With this in mind, the following restrictins apply concerning flow in the tranfer of data: 

40 . A Rule may not modify its Input View unless it also happens to be its Output (i.e., INOUT). 

A Rule may not modify the Output View of a module it calls unless it is the same as the modules Input. 

A Rule may not share its Input View with that of its child's Output. View sharing is permitted between Rules of the 
45 same level and when the Views are the same Usage (i.e., both Input) 

Output View of Rules and the Input Views of modules it calls, are cleared upon invocation, as are locally declared 
Views. 

50 Converse Support Structures 

The CONVERSE WINDOW supports communication between Rules programs in the personal computer environ- 
ment and the user of a system. 

The statement has the form: 
55 CONVERSE WINDOW W I N DOW_N AM E 

where WINDOW_NAME is the name given to the display when it was entered into the HPS Repository. 

Note that there is a difference between Wl N DOW_N AM E and Window View. Each WINDOW_NAME is associated 
with a View which is called its Window View. Not every View in the Repository can be used as a Window View. A Window 



48 



EP 0 502 975 B1 



View can only have a 01 level, 03 level, and 05 level. Note that a Rule can have more than one Converse statement 
but never more than one Window Name. Note also that only PC-based Rules can have Converse statements. 

Asynchronous Support Structures 

This appendix summarizes the rule language constructs that invoke the unsolicited data output (UD) processes. 
Unsolicited data allows a one rule to send data to another Rule without the latter Rule asking for it. This is supported 
using the following statements: 

. ASYNC ATTACH 

ASYNC DETACH 
. ASYNC REFRESH 

ASYNC ROUTE 

The following discussion relates to a hardware configuration with an architecture comprised of an IBM mainframe 
supported by the CICS operating system, a Status mini computer and a bank of PC work stations. All of these constructs 
are currently confined to PC based rules. There also exist Stratus subroutines to execute the following statements. 

In defining the PC constructs, we will assume the existence of the following Rule entity instances: 



rpd 


A PC Rule conversing Window wpd 


rpc2 


A PC Rule conversing Window wpc2 


rpc3 


A PC Rule refreshing wpd 


rpc4 


A PC Rule refreshing wpc2 


rst1 


A Stratus Rule invoking a component which uses the send_message subroutine 



ASYNC ATTACH STATEMENT 



Syntax 

The ASYNC ATTACH statement has the following form: 

ASYNC ATTACH RULE rpc3 VIA RULE rst1 
This command, will initiate the receiving of unsolicited input by the PC Rule rpc3 sent by the Stratus Rule rst1 . 

Semantic Checking 

ATTAC can only be used if: 
Execution environment (Repository attribute of the ATTACH'ed rule is PC and VIA RULE is STRAT) 

ASYNC DETACH Statement 

Syntax 

The ASYNC DETACH statement has the following form: 

ASYNC DETACH RULE rpc3 VIA RULE rst1 

This command performs the exact revers of ATTACH. It may only be used after an ATTACH command, at which 
point it will discontinue the reveiving of unsolicited input by the PC Rule rpc3 sent by the Stratus Rule rst1 . 

Semantic Checking 

Same as for ATTACH. 
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ASYNC ROUTE Statement 
Syntax 

5 The ASYNC ROUTE statement has the following form: 

ASYNC ROUTE RULE rpc3 VIA RULE rpc4 
This command will switch the action of refreshing a Window from the PC Rule rpc3 to teh PC Rule rpc4. 

Semantic Checking 

10 

ROUTE can only be used if: 
Execution environment (Repository attribute) of both 
Rules is the PC. 

is ASYNC REFRESH Statement 

Syntax 

The ASYNC REFRESH statement has the following form: 

20 



ASYNC REFRESH WINDOW wpcl 

(FIELD field_name 

VIEW view_name 

OCCUR field occur 
BEEP ~ 
FLASH ) 



30 where wpd is a Window name and Field_name, view_name and field_occur identify a specific field in this Window. 
This command will induce the automatic updating of the field specified, so long as the Rule is ATTACH'ed. 

Semantics 

35 Assume for the following that Window wpcl View wv1 which contains an occuring array V1 ( a List Box) associated 

with V1 in turn, includes a field F1 . The following command: 
ASYNC REFRESH window wpcl [refresh options] 

with Refresh options BEEP and/or FLASH will cause a beep and/or flashing of the a data being refreshed. Either, both, 

or none of those options may be specidied. 
*o Other refresh Keywords are: 

1. FIELD F1 

VIEW V1 
OCCUR I 

45 Result: The List Box V1 will have F1 or V1 OF WV1 (i) refreshed. 

2. FIELD F1 

VIEW V1 

Result: Every occurence of teh field F1 in V1 would be refreshed (i.e., the column). 

a view vi 

50 OCCUR I 

Result: The List Box v1 will have the i'th row refreshed. 
4. VIEW V1 

Result: The entire List Box v1 will be refreshed! 

55 in options 1 and 2, the VIEW clause can be omitted but only if F1 of wv1 is unique within the Rule. 

In the above, 

F1 can be the literal name of the field or a variable which contains the name (i.e., is either a character or a field 
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oftype CHAR) 

V1 can be the literal name of the view or a variable which contains the name (i.e.,.. is either a character or a field 
of type CHAR) 

5 

i is either an interger or a field of type INTEGER. 
Semantic Checking 
10 . WINDOW clause is mandatory . 

The VIEW clause, if given, must specify a sub-View of the view identifief by the WINDOW clause. 

The FIELD clause, if given, must specify a Field name Included in the View identified by the View clause. 

15 

It OCCUR is used the View identified by the VIEW clause must be an occuring View. 
The OCCUR literal must be within bounds. 
20 Guidelines Concerning Usage of ASYNCH 

A Rule cannot certain both CONVERSE statements and ASYNC statements 

A Rule which CONVERSES cannot USE a Rule with ASYNC statement and vice versa. 

25 

A Rule given the Repository defined attribute ASYNC, cannot have A USE.. ..NEST statement (because NEST 
implies that somewhere in the hierarchy of the rules it calls or in itself, there will be a Rule with a CONVERSE). 

Each Wl N DO W_N AME is associated with a View, called Window View. Not any View in the Repository can be 
30 used as a Window View. A Window View can only have an 01 level, 03 level, and 05 level. Note that a Rule can have 
more than one Converse statement but never more than one Window Name. Note also that only PC-based Rules can 
have Converse statements. 



35 Claims 

1 . A method of operating a data processor to generate and distribute a computer program in a computer system, the 
computer system comprising a plurality of hardware components coupled to form an interconnected computer 
network wherein features relating to a specification of the computer program are specified in terms of data entities 
40 and relationships, characterized in that : 

a. the data processor accepts as input data relating to a task to be performed by the computer program, the 
input data characterized according to a pre-selected set of data entities, said data entities comprising pre- 
selected categories; 

45 b. the data processor accepts as input to the data processor information to link the data entities according to 

a pre-selected set of data relationships, said data relationships comprising pre-selected identifying character- 
istics between data entities; 

c. the data processor operates to link the input data entities to each other according to the input set of data 
relationships, said linked set of data entities and data relationships forming a data model for the data to be 

50 used by the computer program; 

d. the data processor operates to store the linked set of data entities and data relationships in a storage area; 

e. the data processor accepts as input data processor information on the functioning of the computer program 
in the form of specifications for a hierarchical process model, said hierarchial process model comprising a 
representation which divides the function of the computer into discrete tasks, said discrete tasks comprising 

55 descriptions of the functions of pre-selected sections of the computer program and the processing require- 

ments for implementing those functions, said descriptions grouped into a pre-selected set of process entities, 
said process entities comprising pre-selected process categories; 

f. the data processor accepts as input information to link said process entities according to a pre-selected set 
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of process relationships, said process relationships comprising descriptions to identify dependencies between 
the process entities; 

g. the data processor operates to link the process entities according to the pre-selected set of process rela- 
tionships to create the hierarchical process module; 

h. the data processor operates to store the hierarchical process model in the storage area; 

i. the data processor accepts as input information specifying connectivity data for the computer network and 
operational requirements for the operating environments of pre-selected ones of the hardware components; 
j. the data processor operates to store the connectivity data and operational requirement information in the 
storage area; 

k. the data processor accepts as input information to link the connectivity data and operational requirement 
information of the hardware components to pre-selected ones of the process entities to specify the operating 
environment for execution of the pre-selected ones of the process entitles; 

I. the data processor operates to link the connectivity data and operational requirement information of the 
hardware components to the pre-selected ones of the process entities; 

m. the data processor accepts as input information comprising environment independent logic constructs in 
a first programming language, said logic constructs comprising statements in the first computer programming 
language that will enable the computer hardware components to perform the discrete tasks specified in pre- 
selected corresponding ones of the process entities, said first programming language comprising statements 
that reference pre-selected ones of the process entities and the linked set of data entities and data relation- 
ships; 

n. the data processor accepts as input information that relates each logic construct to a pre-selected corre- 
sponding process entity, the logic construct being designed to perform the function specified by its correspond- 
ing process entity; 

o. the data process operates to link each logic construct to a corresponding process entity according to the 
relating information; 

p. the data processor operates to store the linked logic constructs and the corresponding input which relates 
the logic constructs to a process entity in the storage area; 

q. the data processor operates to generate computer program modules by utilizing the logic constructs, the 
corresponding pre-selected ones of the process entities, other pre-selected ones of the hierarchical process 
model, the linked set of data entities and relationships, and the input information that specifies the connectivity 
data of the hardware components linked to the pre-selected corresponding ones of the process entities, said 
computer program modules each comprising computer code that is supported by the operating environment 
of the hardware component linked to the corresponding pre-selected one of the process entities. 



The method of claim 1 further characterized in that : 

a. the data processor operates to scan the storage area to associate with each generated code module the 
linked ones of the hardware components; and 

b. the data processor operates to distribute each generated code module to the linked ones of the hardware 
components. 

The method of claim 1 further characterized in that: each computer code module comprises a source code module. 

The method of claim 2 further characterized in that: each source code module is distributed to its corresponding 
hardware component. 

The method of claim 4 further characterized in that: each hardware component operates to create an object code 
module for each source code module distributed to the hardware component by compiling the source code module. 

The method of claim 3 further characterized in that : 

a. the data processor operates to create object code modules for the computer program by compiling each 
source code module; and 

b. each object code module is distributed to its corresponding hardware component. 

The method of claim 3 further characterized in that the source code comprises statements in a second high-level 
computer programming language. 



52 




EP 0 502 975 B1 



8. The method of claim 3 further characterized in that the source code comprises statements in a third-generation 
programming language that is supported by the operating environment of a pre-selected hardware component. 

9. The method of claim 7 further characterized in that the source code comprises statements in COBOL 

5 

10. The method of claim 7 further characterized in that the source code comprises statements in C. 

11. The method of claim 1 further characterized in that each computer code module comprises an object code module. 
10 12. The method of claim 3 further characterized in that : 

a. a data processor operates to compile each said generated source code module and create a corresponding 
object code module that is executable in the operating environment of the pre-selected ones of the corre- 
sponding hardware components; and 

is b. a data processor operates to link each generated object code module to pre-selected other ones of the 

object code modules, according to the process relationships specified by the hierarchical process model. 

13. The method of claim 1 further characterized in that : 

20 a. a computer code component module is provided in a data processor that is configured to perform a pre- 

selected function and is capable of executing in the operating environments of pre-selected ones of the hard- 
ware components; 

b. preselected component entities are provided in the hierarchical process model which describe the function- 
ing and operational requirements of the object code component modules; 

2$ c. the data processor operates to link each component entity to its corresponding computer code component 

module; 

d. said computer code component module is stored in a memory in pre-selected ones of the hardware com- 
ponents; 

e. the process entities which describe the components and the linking information that references the corre- 
30 sponding computer code component modules are stored in the storage area; 

f. information to link each of the component entities to a preselected process entity in the hierarchical process 
model is accepted as input to the data processor; and 

g. the computer operates to link each of the component entities to a corresponding pre-selected process entity 
in the hierarchical process model. 

35 

14. The method of claim 13 further characterized in that the data processor accepts as input preselected statement 
in the first computer language that reference the computer code component modules. 

15. The method of claim 1 3 further characterized in that the data processor accepts as input preselected statements 
^0 in the first computer language that reference the component entities. 

16. The method of claim 1 3 further characterized in that the computer code component module comprises object code 
statements, said object code statements capable of execution in an operating environment of a corresponding 
hardware component. 

45 

17. The method of claim 13 further characterized in that the computer code component module performs a graphic- 
based user interface function. 

18. The method of claim 1 3 further characterized in that the computer code component module performs the transfer 
so of data between two pre-selected object code modules. 

19. The method of claim 1 3 further characterized in that the computer code component module performs the transfer 
of data between two pre-selected computer code modules designated to operate in the operating environments 
of two different hardware components. 

55 

20. The method of claim 2 further characterized in that: 

a. the data processor accepts as input security access input data comprising information concerning which 
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users may access the computer program and which ones of the preselected hardware components have 
security clearance to execute the computer program; and 

b. the data processor operates to limit the distribution of the computer code modules to the pre-selected hard- 
ware components according to the security access input. 

21. The method of claim 20 further characterized in that the data processor operates to permit the users access to 
the computer program according to the security access input. 

22. The method of claim 2 further characterized in that: 

a. the data processor accepts as input information to modify the first computer programming language state- 
ments of a logic construct; 

b. the data processor operates to search the storage area and determine if the modification necessitates 
changes to linked entities in the hierarchical process model; 

c. the data processor operates to generate new computer code by utilizing the modified logic constructs, the 
corresponding preselected ones of the process entities, other pre-selected ones of the hierarchical process 
model, the linked set of data entities and relationships, and said input information specifying connectivity data 
of the hardware components linked to the pre-selected corresponding ones of the process entities; and 

d. the data processor operates to distribute the new computer code modules to the operating environments 
of corresponding ones of the preselected hardware components. 

23. The method of claim 22 further characterized in that the new computer code modules are distributed to the hardware 
components according to security access input, said security access input comprising information concerning 
which users may access the computer program and which ones of the preselected hardware components have 
security clearance to execute the computer program. 

24. The method of claim 2 further characterized in that: 

a. the data processor accepts as input information to modify data contained in preselected ones of the process 
entities or the process relationships between two process entities; 

b. the data processor operates to search the storage area to determine if the modification information neces- 
sitates changes to linked logic constructs; 

c. the data processor operates to execute modifications to the linked logic constructs necessitated by the 
changes to the pre-selected ones of the process entities; 

d. the data processor operates to generate new computer code by utilizing the modified logic constructs, the 
corresponding preselected ones of the process entities, other pre-selected ones of the hierarchical process 
model, the linked set of data entities and relationships, and said input information specifying connectivity data 
of the hardware components linked to the pre-selected corresponding ones of the process entities; and 

e. the data processor operates to distribute the new computer code modules to the operating environments 
of corresponding ones of the preselected hardware components. 

25. The method of claim 24 further characterized in that: 

a. the data processor operates to search the storage area to determine if the modification information neces- 
sitates changes to the linked set of data entities and relationships; and 

b. the data processor operates to execute modifications to the linked set of data entities and relationships that 
are necessitated by the changes to the preselected ones of the process entities. 

26. The method of claim 2 further characterized in that: 

a. the data processor accepts as input information to modify the pre-selected categories contained in pre- 
selected ones of the data entities or the data relationships between two data entities; 

b. the storage area is searched to determine if the modification necessitates changes to linked logic constructs 
or the hierarchical process model; 

c. the data processor operates to search the storage area to determine if the modification information neces- 
sitates changes to the linked set of process entities and relationships in the hierarchical process model: 

d. the data processor operates to execute modifications to the linked set of process entities and relationships 
that are necessitated by the changes to the preselected ones of the linked set of data entities and relationships; 
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e. the data processor operates to execute modifications to the linked logic constructs necessitated by the 
changes to the pre-selected ones of the linked set of data entities and relationships; 

f. the data processor operates to generate new computer code by utilizing the modified logic constructs, the 
corresponding preselected ones of the process entities, other pre-selected ones of the hierarchical process 

5 model, the linked set of data entities and relationships, and said input information specifying connectivity data 

of the hardware components linked to the pre-selected corresponding ones of the process entities; and 

g. the data processor operates to distribute the new computer code modules to the operating environments 
of corresponding ones of the preselected hardware components. 

10 27. The method of claim 1 further characterized in that: 

a. the data processor accepts as input additional information relating to the functioning of a second computer 
program; 

b. the data processor operates to search the storage area for groups of previously existing process entities 
is and relationships in the storage area which describe process functions that are similar to the desired functioning 

of the second computer program; and 

c. the part of the hierarchical process model and the logic constructs and computer code modules that describe 
functions that are similar to the desired functioning of the second computer program are reused. 

20 28. The method of claim 27 further characterized in that: 

a. the data processor accepts as input additional information relating to the function of the second computer 
program; 

b. the data processor operates to add the additional information to the corresponding reused process entities 
25 of the hierarchical process model; and 

c. the data processor operates to store the process entities containing the additional information relating to 
the functbning of the second computer program in the storage area. 

29. The method of claim 27 further characterized in that: 

a. the data processor accepts as input additional information relating to the function of the second computer 
program, the information specified according to new ones of the pre-selected set of process entities; 

b. the data processor accepts as input data to link each of the new ones of the process entities to one or more 
other new or existing process entities by one of the preselected set of process relationships; 

c. the data processor operates to link each of the new ones of the process entities to one or more other new 
or existing process entities by one of the pre-selected set of process relationships to create a new hierarchical 
process module; and 

d. the new hierarchical process model is stored in the storage area. 
^o 30. The method of claim 29 further characterized in that: 

a. an operating environment corresponding to one of the pre-selected hardware components is specified for 
each new logical construct; 

b. the data processor operates to utilize the first programming language statements in each new logical con- 
struct, the corresponding pre-selected ones of the process entities, other pre-selected ones of the hierarchical 
process model, the linked set of data entities and relationships, and the input information that specifies the 
connectivity data of the hardware components linked to the pre-selected corresponding ones of the process 
entities; and 

c. the data processor operates to distribute the new computer code modules to the operating environments 
of corresponding ones of the preselected hardware components. 

31. The method of claim 1 further characterized in that each of the steps a-q of claim 2 are executed in one of the 
hardware components. 

55 32. The method of claim 30 further characterized in that each of the steps a-c are executed in one of the hardware 
components. 

33. The method of claim 1 further characterized in that the storage area comprises a relational data base located in 
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a preselected one of the hardware components. 



PatentansprOche 

1 . Verfahren zum Betreiben eines Datenprozessors zum Erzeugen und Verteilen eines Computerprogramms in einem 
Computersystem, das eine Mehrzahl von Hardwarekomponenten aufweist, die verbunden sind, urn ein zusam- 
mengeschattetes Computernetzwerk auszubilden, wobei Merkmale, die sich auf die Spezifikation des Computer- 
programms beziehen, in Form von Datenelementen und Datenbeziehungen spezifiziert sind, dadurch gokenn- 
zelchnet: 

a. daB der Datenprozessor als Eingabe Daten akzeptiert, die sich auf eine von dem Computerprogramm aus 
zufGhrende Aufgabe beziehen, wobei die Eingabedaten gemaB einem vorausgewahlten Satz von Datenele- 
menten charakterisiert sind, wobei diese Datenelemente vorausgewahlte Kategorien aufweisen, 

b. daB der Datenprozessor als Eingabe in den Datenprozessor Informationen zum Verknupfen der Datenele- 
mente gemaB einem vorausgewahlten Satz von Datenbeziehungen akzeptiert, wobei diese Datenbeziehun- 
gen vorausgewahlte identifizierende Eigenschalten zwischen den Datenelementen aufweisen. 

c. daB der Datenprozessor arbeitet, um die Eingabedatenelemente gemaB dem Eingabesatz der Datenbe- 
ziehungen miteinander zu verknupfen, wobei dieser verknupfte Satz von Datenelementen und Datenbezie- 
hungen ein Datenmodell fur die von dem Computerprogramm zu verwendenden Daten bildet, 

d. daB der Datenprozessor arbeitet, um den verknupften Satz von Datenelementen und Datenbeziehungen 
in einem Speicherbereich zu speichern, 

e. daB der Datenprozessor als Eingabedaten Prozessorinformationen uber den Ablauf des Computerpro- 
gramms in der Form von Spezifikationen fur ein hierarchisches ProzeBmodell akzeptiert, wobei das hierarchi- 
sche ProzeBmodell eine Darstellung aufweist die die Funktion des Computers in diskrete Aufgaben aufteilt. 
wobei die diskreten Aufgaben Beschreibungen der Funktionen vorausgewahlter Abschnitte des Computer- 
programms und die Verarbeitungsanforderungen fur das Implementieren dieser Funktionen aufweist, wobei 
diese Beschreibungen zu einem vorausgewahlen Satz von ProzeBelementen gruppiert sind, wobei die Pro- 
zeBelemente vorausgewahlte ProzeBkategorien aufweisen, 

f. daB der Datenprozessor als Eingabe Informationen zum Verknupfen dieser ProzeBelemente gemaB einem 
vorausgewahlten Satz von ProzeBbeziehungen akzeptiert, wobei diese ProzeBbeziehungen Beschreibungen 
aufweisen, um Abhangigkeiten zwischen den ProzeBelementen zu identifizieren, 

g. daB der Datenprozessor arbeitet, um die ProzeBelemente gemaB dem vorausgewahlten Satz von 
ProzeBbeziehungen zu verknupfen, um das hierarchische ProzeBmodul zu erzeugen, 

h. daB der Datenprozessor arbeitet, um das hierarchische ProzeBmodell in dem Speicherbereich zu speichern, 

i. daB der Datenprozessor als Eingabe Informationen akzeptiert, die Verschaltungedaten zu dem Computer- 
netzwerk und Betriebsanforderungen an die Betriebsumgebungen von vorausgewahlten Hardwarekomponen- 
ten spezifizieren, 

j. daB der Datenprozessor arbeitet, um die Verschaltungsdaten- und Betriebsanforderungsinformationen in 
dem Speicherbereich zu speichern, 

k. daB der Datenprozessor als Eingabe Informationen zum Verknupfen der Verschaltungsdaten- und Betriebs- 
anforderungsinformationen zu den Hardwarekomponeneten mit vorausgewahlten ProzeBelementen, um die 
Betriebsumgebung fur die Ausfuhrung von vorausgewahlten ProzeBelementen zu spezifizieren, akzeptiert, 
I. daB der Datenprozessor arbeitet, um die Verschaltungsdaten- und Betriebsanforderungsinformationen zu 
den Hardwarekomponenten mit den vorausgewahlten ProzeBelementen zu verknupfen, 
m. daB der Datenprozessor als Eingabe Informationen akzeptiert, die umgebungsunabhangige logische Kon- 
strukte in einer ersten Programmiersprache aufweisen, wobei die logischen Konstrukte Anweisungen in der 
ersten Computerprogrammiersprache aufweisen, die es den Computerhardwarekomponenten ermoglichen, 
die in vorausgewahlten entsprechenden ProzeBelementen spezifizierten diskreten Aufgaben auszufuhren. 
wobei die erste Programmiersprache Anweisungen aufweist, die auf vorausgewahlte ProzeBelemente und 
den verknupften Satz von Datenelementen und Datenbeziehungen Bezug nehmen, 

n. daB der Datenprozessor als Eingabe Informationen akzeptiert, die jedes logische Konstrukt mit einem ent- 
sprechenden vorausgewahlten ProzeBelement in Beziehung setzen. wobei das logische Konstrukt so ausge- 
bildet ist, daB es die Funktion, die durch sein entsprechendes ProzeBelement spezifiziert ist, ausfuhrt, 
o. daB der Datenprozessor arbeitet, um gemaB den Beziehungsinformationen jedes logische Konstrukt mit 
einem entsprechenden ProzeBelement zu verknupfen, 

p. daB der Datenprozessor arbeitet, um die verknupften logischen Konstrukte und die entsprechende Eingabe, 
die die logischen Konstrukte mit einem ProzeBelement in Beziehung setzt, in dem Speicherbereich zu spei- 
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chern, 

q. daG der Datenprozessor arbeitet, um Computerprogrammmodule unter Verwendung der logischen Kon- 
stnjkte, dor entsprechenden vorausgewahlten ProzeGelemente, anderer vorausgewahlter ProzeGelemente 
deshierarchischen ProzeGmodells, des verknOpften Satzes von Datenelementen und Datenbeziehungen und 
der Eingabeinformationen, die die mil den vorausgewahlten entsprechenden ProzeGelementen verknOpften 
Verschallungedaten zu den Hardwarekomponenten spezrfizi eren, zu erzeugen, wobei die Computerpro- 
grammodule jeweils einen Computercode aufweisen, der von der Betriebsumgebung der Hardwarekompo- 
nente unterstOtzt wird, die mit dem entsprechenden vorausgewahlten ProzeGelement verknOpft ist. 

2. Verfahren nach Anspruch 1 , weiterhin dadurch gekennzelchnet: 

a. daG der Datenprozessor arbeitet, um den Speicherbereich abzutasten, um jedes erzeugte Codemodul den 
verknOpften Hardwarekomponenten zuzuordnen, und 

b. daG der Datenprozessor arbeitet, um jedes erzeugte Codemodul an die verknOpften Hardwarekomponenten 
zu verteilen. 

3. Verfahren nach Anspruch 1 , weiterhin dadurch gekennzeichnet: daG jedes Computercodemodul ein Quellcode- 
modul aufweist. 

4. Verfahren nach Anspruch 2, weiterhin dadurch gekennzelchnet: daB jedes Quellcodemodul an seine entspre- 
chende Hardwarekomponente verteilt wird. 

5. Verfahren nach Anspruch 4, weiterhin dadurch gekennzelchnet: daG jede Hardwarekomponente arbeitet, um 
ein Objektcodemodul f Or jedes Quellcodemodul, das an die Hardwarekomponente verteilt wird, durch Kompilieren 
des Quellcodemoduls zu erzeugen. 

6. Verfahren nach Anspruch 3, weiterhin dadurch gekennzeichnet: 

a. daG der Datenprozessor arbeitet, um Objektcodemodule fur das Computerprogramm durch Kompilieren 
jedes Quellcodemodule zu erzeugen, und 

b. daG jedes Objektcodemodul an seine entsprechende Hardwarekomponente verteilt wird. 

7. Verfahren nach Anspruch 3, weiterhin dadurch gekennzelchnet, daG der Quellcode Anweisungen in einer zwei- 
ten, hoheren Computerprogramm iersprache aufweist. 

8. Verfahren nach Anspruch 3, weiterhin dadurch gekennzeichnet, daG der Quellcode Anweisungen in einer Pro- 
gramm iersprache der dritten Generation aufweist, die von der Betriebsumgebung einer vorausgewahlten Hard- 
warekomponente unterstutzt wird. 

9. Verfahren nach Anspruch 7, weiterhin dadurch gekennzeichnet, daG der Quellcode Anweisungen in COBOL 
aufweist. 

10. Verfahren nach Anspruch 7, weiterhin dadurch gekennzeichnet, daG der Quellcode Anweisungen in C aufweist. 

11. Verfahren nach Anspruch 1, weiterhin dadurch gekennzelchnet, daG jedes Computercodemodul ein Objektco- 
demodul aufweist. 

12. Verfahren nach Anspruch 3, weiterhin dadurch gekennzeichnet: 

a. daG der Datenprozessor arbeitet, um jedes der erzeugten Quellcodemodule zu kompilieren und um ein 
entsprechendes Objektcodemodul zu erzugen, das in der Betriebsumgebung der vorausgewahlten entspre- 
chenden Hardwarekomponente ausfuhrbar ist, und 

b. daG der Datenprozessor arbeitet, um jedes erzeugte Objektcodemodul mit einem vorausgewahlten anderen 
Objektcodemodul gemaG der ProzeGbeziehung, die durch das hierarchische ProzeGmodell spezifiziert ist, zu 
verknupfen. 

13. Verfahren nach Anspruch 1, weiterhin dadurch gekennzeichnet: 
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a. daB ein Computercodekomponentenmodul in einem Datenprozessor vorgesehen ist, der konfiguriert ist, 
urn eine vorausgewahlte Funktion auszufuhren, und derzum Ausfuhren (der Funktion) in den Betriebsumge- 
bungen von vorausgewahlten Hardwarekomponenten geeignet ist, 

b. daB vorausgewahlte Komponentenelemente in dem hierarchischen ProzeBmodell vorgesehen sind, die die 
Funktions- und Betriebsanforderungen der Objektcodekomponentenmodule beschreiben, 

c. daB der Datenprozessor arbeitet, urn jedes Komponentenelement mit seinem entsprechenden Computer- 
codekomponentenmodul zu verknupfen, 

d. daB das Computercodekomponentenmodul in einem Speicher in vorausgewahlten Hardwarekomponenten 
gespeichert wird, 

e. daB die ProzeBelemente, die die Komponenten und die auf die entsprechenden Computercodekomponen- 
tenmodule Bezug nehmenden Verknupfungsinformationen beschreiben, in dem Speicherbereich gespeichert 
werden, 

f. daB Informationen zum Verknupfen jedes Komponenten elements mit einem vorausgewahlten ProzeBele- 
ment in dem hierarchischen in ProzeBmodell als Eingabe in den Datenprozessor akzeptiert werden und 

g. daB der Computer arbeitet, urn jedes Komponentenelement mit einem entsprechenden vorausgewahlten 
ProzeBelement in dem hierarchischen ProzeBmodell zu verknupfen. 

14. Verfahren nach Anspruch 1 3, weiterhin dadurch gekennzeichnet, daB der Datenprozessor als Eingabe voraus- 
gewahlte Anweisungen in der ersten Computersprache akzeptiert, die auf die Computercodekomponentenmodule 
Bezug nehmen. 

15. Verfahren nach Anspruch 13, weiterhin dadurch gekennzeichnet, daB der Datenprozessor als Eingabe voraus- 
gewahlte Anweisungen in der ersten Computersprache akzeptiert ; die auf die Komponentenelemente Bezug neh- 
men. 

16. Verfahren nach Anspruch 13, weiterhin dadurch gekennzeichnet, daB das Computercodekomponentenmodul 
Objektcodeanweisungen aufweist, wobei dieObjektcodeanweisungen zur Ausfuhrung in einer Betriebsumgebung 
einer entsprechenden Hardwarekomponente geeignet sind. 

17. Verfahren nach Anspruch 13, weiterhin dadurch gekennzeichnet, daB das Computercodekomponentenmodul 
eine graphisch gestutzte Benutzerschnittstellenfunktion ausfuhrt. 

18. Verfahren nach Anspruch 13, weiterhin dadurch gekennzeichnet, daB das Computercodekomponentenmodul 
den Transfer von Daten zwischen zwei vorausgewahlten Objektcodemodulen ausfuhrt. 

19. Verfahren nach Anspruch 13, weiterhin dadurch gekennzeichnet, daB das Computercodekomponentenmodul 
den Transfer von Daten zwischen zwei vorausgewahlten Computercodemodulen ausfuhrt, die vorgesehen sind, 
in den Betriebsumgebungen von zwei verschiedenen Hardwarekomponenten zu arbeiten. 

20. Verfahren nach Anspruch 2, weiterhin dadurch gekennzeichnet: 

a. daB der Datenprozessor als Eingabe Sicherheits-zugangseingabedaten akzeptiert, die Informationen dar- 
uber aufweisen, welche Benutzer Zugang zu dem Computerprogramm und welche vorausgewahlten Hard- 
warekomponenten Sicherheitsfreigaben zum Ausfuhren des Computerprogramms haben, und 

b. daB der Datenprozessor arbeitet, urn die Verteilung der Computercodemodule an die vorausgewahlten 
Hardwarekomponenten gemaB der Sicherheitszugangseingabe zu beschranken. 

21. Verfahren nach Anspruch 20, weiterhin dadurch gekennzeichnet, daB der Datenprozessor arbeitet, urn den Be- 
nutzern den Zugang zu dem Computerprogramm gemaB der Sicherheitszugangseingabe zu erlauben. 

22. Verfahren nach Anspruch 2, weiterhin dadurch gekennzeichnet: 

a. daB der Datenprozessor als Eingabe Informationen zum Modifizieren der in der ersten Computerprogram- 
miersprache gehaltenen Anweisungen eines logischen Konstrukts akzeptiert, 

b. daB der Datenprozessor arbeitet, um den Speicherbereich zu durchsuchen und um festzustellen, ob die 
Modifikation Anderungen der verknupften Elemente in dem hierarchischen ProzeBmodell erforderlich macht, 

c. daB der Datenprozessor arbeitet, um neue Computerprogrammodule unter Verwendung der modifizierten 
logischen Konslrukte, der entsprechenden vorausgewahlten ProzeBelemente, anderer vorausgewahlter Pro- 
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zeBelemente des hierarchischen ProzeBmodells, des verknupften Satzes von Datenelementen und Datenbe- 
ziehungen und der Eingabeinformationen, die die mit den vorausgewahlten entsprechenden ProzeBelementen 
verknupften Verschaltungsdaten zu den Hardwarekomponenten spezifizieren, zu erzeugen, und 
d. daB der Datenprozessor arbeitet, um die neuen Compute rprogrammodule an die Betriebsumgebungen der 
s entsprechenden vorausgewahlten Hardwarekomponenten zu verteilen. 

23. Verfahren nach Anspruch 22, weiterhin dadurch gekennzelchnet, daB die neuen Compulercodemodule an die 
Hardwarekomponenten gemaB der Sicherheitszugangseingabe verteilt werden, wobei die Sicherheitszugangs- 
eingabe Informationen daruber aufweist, welche Benutzer Zugang zu dem Computerprogramm und welche vor- 

10 ausgewahlten Hardwarekomponenten Sicherheitsfreigaben zum Ausfuhren des Computerprogramms haben. 

24. Verfahren nach Anspruch 2, weiterhin dadurch gekennzelchnet: 

a. daB der Datenprozessor als Eingabe Informationen zum Modrfizieren der in vorausgewahlten ProzeBele- 
is menten Oder ProzeBbeziehungen zwischen zwei ProzeBelementen enthaltenen Daten akzeptiert, 

b. daB der Datenprozessor arbeitet, um den Speicherbereich zu durchsuchen, um festzustellen, ob die Mo- 
difikationsinformationen Anderungen von verknupften logischen Konstrukten erforderlich machen, 

c. daB der Datenprozessor arbeitet, um Modifikationen an den verknupften logischen Konstrukte auszuf uhren, 
die durch die Anderungen der vorausgewahlten ProzeBelemente erforderlich gemacht wurden, 

20 d. daB der Datenprozessor arbeitet, um neue Computercodemodule unter Verwendung der modifizierten lo- 

gischen Konstrukte, der entsprechenden vorausgewahlten ProzeBelemente, anderer vorausgewahlter Pro- 
zeBelemente des hierarchischen ProzeBmodells, des verknupften Satzes von Datenelementen und Datenbe- 
ziehungen und der Eingabeinformationen, die die m it den vorausgewahlten entsprechenden ProzeBelementen 
verknupften verschaltungsdaten zu den Hardwarekomponenten spezifizieren, zu erzeugen : und 

25 e. daB der Datenprozessor arbeitet, um die neuen Compute rprogrammodule an die Betriebsumgebungen der 

entsprechenden vorausgewahlten Hardwarekomponenten zu verteilen. 

25. Verfahren nach Anspruch 24, weiterhin dadurch gekennzelchnet: 

30 a. daB der Datenprozessor arbeitet, um den Speicherbereich zu durchsuchen, um festzustellen, ob die Mo- 

difikations information en Anderungen des verknupften Satzes von Datenelementen und Datenbeziehungen 
erforderlich machen, und 

b. daB der Datenprozessor arbeitet, um Modifikationen an dem verknupften Satz von Datenelementen und 
Datenbeziehungen auszuf uhren, die durch die Anderungen der vorausgewahlten ProzeBelemente erforderlich 
35 gemacht wurden. 

26. Verfahren nach Anspruch 2, weiterhin dadurch gekennzelchnet: 

a. daB der Datenprozessor als Eingabe Informationen zum Modifizieren der in vorausgewahlten Daten ele- 
40 menten oder Datenbeziehungen zwischen zwei Datenelementen enthaltenen vorausgewahlten Kategorien 

akzeptiert, 

b. daB der Speicherbereich durchsucht wird, um festzustellen, ob die Mod if ikation Anderungen der verknupften 
logischen Konstrukte oder des hierarchischen ProzeBmodells erforderlich macht, 

c. daB der Datenprozessor arbeitet, um den Speicherbereich zu durchsuchen, um festzustellen, ob die Modi- 
45 fikationsinformationen Anderungen des verknupften Satzes von ProzeBelementen und ProzeBbeziehungen 

in dem hierarchischen ProzeBmodell erforderlich machen, 

d. daB der Datenprozessor arbeitet, um Modifikationen an dem verknOpflen Satz von ProzeBelementen und 
ProzeBbeziehungen auszufuhren, die durch die Anderungen der vorausgewahlten Datenelemente und Da- 
tenbeziehungen des verknupften Satzes von Datenelementen und Datenbeziehungen erforderlich gemacht 

so wurden, 

e. daB der Datenprozessor arbeitet, um Modifikationen an den verknupften logischen Konstrukten auszufuh- 
ren, die durch die Anderungen der vorausgewahlten Datenelemente und Datenbeziehungen des verknupften 
Satzes von Datenelementen und Datenbeziehungen erforderlich gemacht wurden, 

f . daB der Datenprozessor arbeitet, um neue Computercodemodule unter Verwendung der modifizierten logi- 
cs schen Konstrukte, der entsprechenden vorausgewahlten ProzeBelemente, anderer vorausgewahlter 

ProzeBelemente des hierarchischen ProzeBmodells, des verknupften Satzes von Datenelementen und Da- 
tenbeziehungen und der Eingabeinformationen, die die mit den vorausgewahlten entsprechenden ProzeBele- 
menten verknupften Verschaltungsdaten zu den Hardwarekomponenten spezifizieren, zu erzeugen, und 
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g. daB der Datenprozessor arbeitet, urn die neuen Compute rcodemodule an die Betriebsumgebungen der 
entsprechenden vorausgewahlten Hardwarekomponenten zu Verteilen. 

27. Verfahren nach Anspruch 1, weiterhin dadurch gekennzelchnet: 

a. daB der Datenprozessor als Eingabe zusatzliche Informationen akzeptiert, die sich auf den Ablaut eines 
zweiten Computerprogramms beziehen, 

b. daB der Datenprozessor arbeitet, um den speicherbereich nach Gruppen von bereits in dem Speicherbe- 
reich existierenden ProzeBelementen und ProzeBbeziehungen zu durchsuchen, die dem gewOnschten Ablaut 
des zweiten Computerprogramms ahnliche ProzeGfunktionen beschreiben, 

c. daB der Teil des hierarchischen ProzeBmodells und der logischen Konstrukte und Compute rmodule, die 
dem gewOnschten Ablaut des zweiten Computerprogramms ahnliche ProzeBfunktionen beschreiben, wieder- 
verwendet werden. 

28. Vertahren nach Anspruch 27, weitemin dadurch gekennzelchnet: 

a. daB der Datenprozessor als Eingabe zusatzliche Intormationen akzeptiert, die sich auf die Funktion des 
zweiten Computerprogramms beziehen, 

b. daB der Datenprozessor arbeitet, um die zusatzliche Information zu den entsprechenden wiederverwende- 
ten ProzeBelementen des hierarchischen ProzeBmodells hinzuzufOgen, und 

c. daB der Datenprozessor arbeitet, um die ProzeBelemente, die die zusatzlichen, sich auf den Ablauf des 
zweiten Computerprogramms beziehenden Informationen enthalten, in dem Speicherbereich zu speichern. 

29. Verfahren nach Anspruch 27, weitemin dadurch gekennzelchnet: 

a. daB der Datenprozessor als Eingabe zusatzliche Informationen akzeptiert, die sich auf die Funktion des 
zweiten Computerprogramms beziehen, wobei die Informationen gemaB neuen ProzeBelementen des vor- 
ausgewahlten satzes von ProzeBelementen spezifiziert sind, 

b. daB der Datenprozessor als Eingabe Daten zum VerknOpfen jedes neuen ProzeB elements mit einem oder 
mehreren anderen neuen oder existierenden ProzeBelemente(n) durch eine ProzeBbeziehung des voraus- 
gewahlten Satzes von ProzeBbeziehungen akzeptiert, 

c. daB der Datenprozessor arbeitet, um jedes neue ProzeBelement mit einem oder mehreren anderen neuen 
oder existierenden ProzeBelemente(n) durch eine ProzeBbeziehung des vorausgewahtten Satzes von Pro- 
zeBbeziehungen zu verknupfen, um ein neues hierarchisches ProzeBmodell zu erzeugen, und 

d. daB das neue hierarchische ProzeBmodell in dem Speicherbereich gespeichert wird. 

30. Verfahren nach Anspruch 29, weiterhin dadurch gekennzelchnet: 

a. daB eine einer vorausgewahlten Hardwarekomponente entsprechende Betriebsumgebung fur jedes neue 
logische Konstrukt spezifiziert wird, 

b. daB der Datenprozessor arbeitet, um die in der ersten Programmiersprache gehaltenen Anweisungen in 
jedem neuen logischen Konstrukt, den entsprechenden vorausgewahlten ProzeBelementen, anderen voraus- 
gewahlten ProzeBelementen des hierarchischen ProzeBmodells, dem verknOpften Satz von Datenelementen 
und Datenbeziehungen und den Eingabeinformationen, die die mit den entsprechenden vorausgewahlten 
ProzeBelementen verknOpften Verschaltungsdaten zu den Hardwarekomponenten spezifizieren, zu verwen- 
den : und 

c. daB der Datenprozessor arbeitet, um die neuen Compute rprog ram module an die Betriebsumgebungen der 
entsprechenden vorausgewahlten Hardwarekomponenten zu verteilen. 

31 . Verfahren nach Anspruch 1 , weiterhin dadurch gekennzelchnet, daB jeder der Schritte a bis q in einer der Hard- 
warekomponenten ausgefOhrt wird. 

32. Verfahren nach Anspruch 30, weiterhin dadurch gekennzelchnet, daB jeder der Schritte a bis c in einer der 
Hardwarekomponenten ausgefOhrt wird. 

33. Verfahren nach Anspruch 1, weiterhin dadurch gekennzelchnet, daB der Speicherbereich eine relationale Da- 
tenbank aufweist, die in einer vorausgewahlten Hardwarekomponente angeordnet ist. 
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Re vend feat ions 

1. Proc6de d' exploitation d'un processeur de donn6es pour generer et distribuer un programme d'ordinateur dans 
un systeme d'ordinateurs, le systeme d'ordinateurs comprenant une pluralite de composants materiels accouples 
pour former un reseau d'ordinateurs interconnect© dans lequel les caracteristiques liees a une specification du 
programme d'ordinateur sont sp6cifiees en termes d'entites de donnees et de relations, caracteris6 en ce que : 

a. le processeur de donnees accepte comme donnees d'entree concemant une tache a executer par le pro- 
gramme d'ordinateur, les donnees d'entree caracterisdes selon un ensemble pr6s6lectionn6 d'entites de don- 
nees, lesdites entites de donnees comportant des categories preselect ion nees ; 

b. le processeur de donnees accepte en entree du processeur de donnees des informations pour relier les 
entites d'entree selon un ensemble preselectionne de relations de donnees, lesdites relations de donnees 
comportant des caracteristiques identifiantes preselectionnees entre des entites d'entree ; 

c. le processeur de donnees a pour fonction de relier les entites de donnees d'entree entre elles selon I'en- 
semble des relations de donnees d'entree, ledit ensemble relie des entites de donnees et des relations de 
donnees formant un modele de donnees pour les donnees a utiliser par le programme d'ordinateur ; 

d. le processeur de donnees a pour fonction de memoriser i'ensemble relie des entites de donnees et des 
relations de donnees dans une zone de memoire ; 

e. le processeur de donnees accepte comme donnees d'entree des informations de processeur au sujet du 
fonctionnement du programme d'ordinateur sous la forme de specifications pour un modele de traitement 
hierarchique, ledit modele de traitement hierarchique comportant une representation, laquelle partage la fonc- 
tion de I'ordinateur en taches discretes, lesdites taches discretes comportant des definitions des fonctions de 
sections preselectionnees du programme d'ordinateur et des conditions de traitement pour la mise en oeuvre 
de ces fonctions, lesdites descriptions group6es en un ensemble pr6seiectionne d'entites de traitement, les- 
dites entites de traitement comportant des categories preselectionnees de traitement ; 

f. le processeur de donnees accepte en entree des informations pour relier lesdites entites de traitement selon 
un ensemble preselectionnS de relations de traitement, lesdites relations de traitement comportant des des- 
criptions pour identifier des dependances entre les entites de traitement ; 

g. le processeur de donnees a pour fonction de relier les entites de traitement selon I'ensemble ptes6lectionne 
de relations de traitement pour cr6er le module de traitement hierarchique ; 

h. le processeur de donnees a pour fonction de memoriser le modele de traitement hierarchique dans la zone 
de memoire ; 

i. le processeur de donnees accepte en entree des informations specifiant des donnees de connexion pour 
le reseau d'ordinateurs et des conditions fonction ne I les pour les environnements d'exploitation de certains 
composants materiels pres6lectionn6s ; 

j. le processeur de donnees a pour fonction de memoriser les donnees de connexion et les informations d' exi- 
gence fonctionnelle dans la zone de memoire ; 

k. le processeur de donnees accepte en entree des informations pour relier les donnees de connexion et les 
informations de condition fonctionnelle des composants materiels a certaines entites de traitement preselec- 
tionnees afin de specifier I'environnement d'exploitation pour I'execution de certaines entites de traitement 
preselectionnees ; 

I. le processeur de donnees a pour fonction de relier les donnees de connexion et les informations de condition 
fonctionnelle des composants materiels a certaines entites de traitement preselectionnees ; 
m. le processeur de donn6es accepte en entree des informations comportant des constructions logiques in- 
dependantes de I'environnement dans un premier langage de prog ram mation, lesdites constructions logiques 
comportant des instructions dans le premier langage de program mat ion d'ordinateur qui permettent aux com- 
posants materiels des ordinateurs d'executer les taches discretes specifies dans certaines entites de traite- 
ment preselectionnees correspondantes, ledit premier langage de programmation comportant des instructions 
qui font reference a certaines entites de traitement preselectionnees, a I'ensemble relie des entites de donnees 
et aux relations de donnees ; 

n. le processeur de donn6es accepte en entr6e des informations qui relient chaque construction logique a 
une entite de traitement pr6s6lectionn6e correspondante, la construction logique 6tant concue pour execute r 
la fonction specif iee par son entite de traitement correspondante ; 

o. le traitement des donnees a pour fonction de relier chaque construction logique a une entite de traitement 
correspondante selon les informations de relation ; 

p. le processeur de donnees a pour fonction de m6moriser les constructions logiques reliees et I'entr6e cor- 
respondante, laquelle relie les constructions logiques a une entite de traitement dans la zone de m6moire ; 
q. le processeur de donn6es a pour fonction de g6n6rer des modules de programme d'ordinateur en utilisant 
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les constructions logiques, celles des entites de traitement preselect ion nees correspondantes, ceux pr6se- 
lectionn6s des autres modeles de traitement hierarchique, Tensemble relie d'entites de donnees et de relations, 
les informations d'entree qui specifient les donnees de connexion des composants materiels relies a certaines 
entites de traitement pres6lectionnees correspondantes, lesdits modules de programme d'ordinateur compor- 
tant chacun un code d'ordinateur qui est supports par I'environnement d'exploitation du composant materiel 
relie a I'entite de traitement correspondante preselectionnee. 

2. Precede sebn la revendication 1 , caracterise en outre en ce que : 

a. le processeur de donnees a pour fonction de balayer la zone de memoire pour associer a chaque module 
de code gendre certains composants materiels relies ; et 

b. le processeur de donnees a pour fonction de distribuer chaque module de code genere a certains compo- 
sants materiels relies. 

3. Procede selon la revendication 1 , caracterise en outre en ce que chaque module de code d'ordinateur comporte 
un module de code source. 

4. Proc6d6 selon la revendication 2, caracterise en outre en ce que chaque module de code source est distribue a 
son composant materiel correspondant. 

5. Procede selon la revendication 4, caracterise en outre en ce que chaque composant materiel a pour fonction de 
crder un module de code objet pour chaque module de code source distribue au composant materiel par compi- 
lation du module de code source. 

6. Procede selon la revendication 3, caracterise en outre en ce que : 

a. le processeur de donnees a pour fonction de creer des modules de code objet pour le programme d'ordi- 
nateur par compilation de chaque module de code source ; et 

b. chaque module de code objet est distribue a son composant materiel correspondant. 

7. Precede selon la revendication 3, caracterise en outre en ce que le code source comporte des instructions en un 
second langage de programmation d'ordinateur de haut niveau. 

8. Procede selon la revendication 3, caracterise en outre en ce que le code source comporte des instructions dans 
un langage de programmation de troisieme generation qui est supporte par I'environnement d'exploitation d'un 
composant materiel ptes6lectionne\ 

9. Procede selon la revendication 7, caracterise en outre en ce que le code source comporte des instructions en 
COBOL. 

10. Precede selon la revendication 7, caracterise en outre en ce que le code source comporte des instructions en 
langage C. 

11. Precede selon la revendication 1 , caract6ris6 en outre en ce que chaque module de code d'ordinateur comporte 
un module de code objet. 

12. Procede sebn la revendication 3, caract6ris6 en outre en ce que : 

a. un processeur de donnees a pour fonction de compiler chacun desdits modules de code source genetes 
et de cr6er un module de code objet correspondant qui est executable dans I'environnement d'exploitation de 
certains composants materiels preseiectionnes correspondants ; et 

b. un processeur de donn6es a pour fonction de relier chaque module de code objet generG a d'autres modules 
de code objet pteseiectionnes selon les relations de traitement specifi6es par le modele de traitement hierar- 
chique. 

13. Procede sebn la revendication 1 , caracterise en outre en ce que : 

a. un module composant de code d'ordinateur est pr6vu dans un processeur de donnees qui est configure 
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pour executer une fonction preseiectbnnee et qui est capable d'execution dans les environnements d'expbi- 
tation de ceux des composants materiels, pr6s6lectionnes ; 

b. des entites pr6s6lectionn6es de composants sont prevues dans te modele de traitement hierarchique, les- 
quel les decrivent le fonctionnement et la condition fonctionnelle des modules composants de code objet ; 
5 c. le processeur de donnees a pour fonction de relier chaque entite composante a son module composant de 

code d'ordinateur correspondant ; 

d. ledit module composant de code d'ordinateur est memorise dans une memoire de certains composants 
materiels preselect ion n6s ; 

e. les entites de traitement qui definissent les composants et les informations de relation qui reterencent les 
10 modules composants des codes d'ordinateur correspondants sont memoris6es dans la zone de memoire ; 

f. les informations pour relier chacune des entites de composant a une entite de traitement presGlectionnee 
dans le modele de traitement hierarchique sont acceptees en entrde du processeur de donnees ; et 

g. I'ordinateur pour fonction de relier chacune des entites composantes a une entite de traitement pr6s6lec- 
tionnSe correspondante dans le modele de traitement hierarchique. 

1S 

14. Procede selon la revendication 13, caracterise en outre en ce que le processeur de donnees accepte en entree 
des instructions pr6s6lectionnees dans le premier langage d'ordinateur qui font reference aux modules compo- 
sants du code d'ordinateur. 

20 15. Proc6de selon la revendication 13, caracterise en outre en ce que le processeur de donnees accepte en entree 
des instructbns pr6s6lectionnees dans le premier langage d'ordinateur qui font reference aux entites composan- 
tes. 

16. Proc6d6 selon la revendication 13, caracterise en outre en ce que le module composant de code d'ordinateur 
25 comports des instructions de code objet, lesdites instructions de code objet etant aptes a I'execution dans un 

environnement d'exploitation d'un composant materiel correspondant. 

17. Proced6 selon la revendication 13, caracterise en outre en ce que le module composant de code d'ordinateur 
execute une fonction d'interface utilisateur a base graphique. 

30 

18. Procede selon la revendication 13, caracterise en outre en ce que le module composant de code d'ordinateur 
execute le transfer! des donnees entre deux modules de code objet pr6s6lectionn6s. 

19. Procede sebn la revendication 13, caract6ris6 en outre en ce que le module de composant de code d'ordinateur 
35 execute le transfert des donn6es entre deux modules de code d'ordinateur pr6s6lectionnes designes pour I'exe- 

cution dans les environnements d'exploitation de deux composants materiels differents. 

20. Proc6d6 sebn la revendication 2, caracterise en outre en ce que : 

40 a. le processeur de donn6es accepte en entree des donnees d'entree d'acces de securite comportant des 

informations concernant quels utilisateurs peuvent acc6der au programme d'ordinateur et ceux parmi les com- 
posants materiels preselectionnes qui ont une distance de security pour executer le programme d'ordinateur ; 
et 

b. le processeur de donnees a pour fonction de limiter la distribution des modules de code d'ordinateur a des 
45 composants materiels select ion n 6s selon I'entr6e d'acces de securite. 

21. Procede sebn la revendication 20, caracterise en outre en ce que le processeur de donnees a pour fonction de 
permettre a des utilisateurs d'acceder au programme d'ordinateur selon I 'entree d'acces de securite. 

so 22. Procede sebn la revendication 2, caracterise en outre en ce que : 

a. le processeur de donnees accepte en entree des informations pour modifier les instructions en premier 
langage de programmation d'ordinateur d'une construction logique ; 

b. le processeur de donnees a pour fonction de rechercher dans la zone de memoire et de determiner si la 
S5 modification ndcessite des changements des entites relives dans le modele de traitement hierarchique ; 

c. le processeur de donnees a pour fonction de g§ne>er un nouveau code d'ordinateur en utilisant les cons- 
tructions logiques modifiees, celles des entites de traitement, correspondantes preselectionn6es, ceux, pre- 
selectionnes, des autres modeles de traitement hierarchique, les ensembles relies d'entites de donnees et de 
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relations, et lesdites informations d'entr6e specifiant les donnees de connexion des composants materials 
relics a celles des entites de traitement, correspondantes pr6s6lectionn6es ; et 

d. le processeur de donnees a pour tonction de distribuer les nouveaux modules de code d'ordinateur aux 
environnements d'exploitation de ceux des composants materiels pr6s6lectionnes, correspondants. 

5 

23. Procede selon la revendication 22, caracterise en outre en ce que les nouveaux modules de code d'ordinateur 
sont distribuSs aux composants materiels selon Pentr6e d'acces de securite, ladite entree d'acces de s6curit6 
comportant des informations concernant quels utilisateurs peuvent acc6der au programme d'ordinateur et ceux 
des composants materials pr6s6lectionnes qui ont una distance de securite pour executer le programme d'ordi- 

10 nateur. 

24. Procede sebn la revendication 2, caracterise en outre en ce que : 

a. le processeur de donnees accepte en entree des informations pour modifier des donnees contenues dans 
is celles des entites de traitement, pr6s6lectionn6es ou les relations de traitement entre deux entites de 

traitement ; 

b. le processeur de donn6es a pour fonction de rechercher dans la zone de memoire pour determiner si les 
informations de modification n£cessitent des changements des constructions logiques reliees ; 

c. le processeur de donnees a pour fonction d'executer des modifications aux constructions logiques reliees 
20 exigees par les modifications de celles des entiles de traitement, preselectionnees ; 

d. le processeur de donnees a pour fonction de g6n6rer un nouveau code d'ordinateur en utilisant les cons- 
tructions logiques modifies, celles des entites de traitement, preselectionnees correspondantes, ou ceux 
presefectionnes des autres modeles de traitement hierarchique. i'ensemble relie d'entites de donn6es et de 
relations, et lesdites informations d'entree specifiant les donnees de connexion des composants materiels 

25 relics a celles des entiles de traitement, preselectionnees correspondantes ; et 

e. le processeur de donnees a pour fonction de distribuer les nouveaux modules de code d'ordinateur aux 
environnements d'exploitation de ceux des composants materiels pr§s6lectionn6s, correspondants. 

25. Proc6d6 sebn la revendication 24, caracterise" en outre en ce que : 

30 

a. le processeur de donnees a pour fonction de rechercher dans la zone de memoire pour determiner si les 
informations de modification nScessitent des changements de I'ensemble relie aes entites de donnees et de 
relations ; et 

b. le processeur de donn6es a pour fonction d'executer des modifications a I'ensemble relie des entites de 
35 donn£es et des relations qui sont exig6es par les changements a celles des entites de traitement, preselec- 
tionnees. 

26. Procede selon la revendication 2, caracterise en outre en ce que : 

40 a. le processeur de donn6es accepte en entree des informations pour modifier les categories pr6seiectionn6es 

contenues dans celles des entites de donn6es ou relations de donn6es entre deux entites de donnees, 
preselectionnees ; 

b. la zone de memoire est recherchee pour determiner si la modification n6cessite d'apporter des changements 
aux constructions logiques reliees ou au mod&le de traitement hierarchique ; 
45 c. le processeur de donnees a pour fonction de rechercher la zone de memoire pour determiner si les infor- 

mations de modification n6cessitent des changements a I'ensemble relie des entites de traitement et des 
relations dans le modele de traitement hierarchique ; 

d. le processeur de donnees a pour fonction d'executer des modifications a I'ensemble relie des entites de 
traitement et des relations qui sont necessaires aux changements a apporter a celles preselect ionn 6s de 

50 I'ensemble relie des relations et des entites de donnees ; 

e. le processeur de donnees a pour fonction d'executer des modifications aux constructions logiques reliees 
exigees par les changements a apporter a celles preselectionnees de I'ensemble relie des relations et des 
entites de donnees ; 

f. le processeur de donnees a pour fonction de g6n6rer un nouveau code d'ordinateur en utilisant les cons- 
55 tructions logiques modiftees, celles des entites de traitement correspondantes preselectionnees, ceux pr6se- 

lectionnes des autres modeles de traitement hierarchique, d'ensembles reli6s de relation et d'entites de don- 
nees et lesdites informations d'entree specifiant des donnees de connexion des composants materiels reli6s 
a celles des entites de traitement, correspondantes preselectionnees ; et 
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g. le processeur de donnees a pour fonction de distribuer les nouveaux modules de code d'ordinateur aux 
environ nements Sexploitation des composants materiels pr6s6lectionnes correspondants. 

27. Procede selon la revendication 1 , caracterisd en outre en ce que : 

5 

a. le processeur de donnees accepte en entree des informations supplementaires concemant le fonctionne- 
ment d'un second programme d'ordinateur ; 

b. le processeur de donnees a pour fonction de rechercher dans la zone de memoire les groupes des entites 
de traitement et des relations existant prec6demment dans la zone de memoire qui definissent des fonctions 

io de traitement qui sont semblables au fonctionnement desire du second programme d'ordinateur ; et 

c. les parties du modele de traitement hterarchique et des constructions logiques et des modules de code 
d'ordinateur qui definissent des fonctions qui sont semblables au fonctionnement desire du second programme 
d'ordinateur sont reutilisees. 

'5 28. Procede selon la revendication 27, caracterise en outre en ce que : 

a. le processeur de donn§es accepte en entree des informations supplementaires reliant la fonction du second 
programme d'ordinateur ; 

b. le processeur de donndes a pour fonction d'ajouter les informations additionnelles des entites de traitement 
20 r6utilis§es correspondantes du modele de traitement hi6rarchique ; et 

c. le processeur de donnSes a pour fonction de mSmoriser les entites de traitement contenant les informations 
additionnelles concemant le fonctionnement du deuxieme programme d'ordinateur dans la zone de nrtemoire. 

29. Procedd selon la revendication 27, caracterise^ en outre en ce que : 

25 

a. le processeur de donnees accepte, comme informations additionnelles d'enttee concemant la fonction du 
deuxieme programme d'ordinateur, les informations specifies selon celles nouvelles de ('ensemble preselec- 
tionne des entites de traitement ; 

b. le processeur de donnees accepte en enttee des donnees pour relier chacune des nouvelles entites de 
30 traitement a une ou plusieurs autres entites de traitement nouvelles ou existantes par I'une de I'ensemble 

ptes6lectionn6 de relations de traitement ; 

c. le processeur de donnees a pour fonction de relier chacune des nouvelles entites de traitement a une ou 
plusieurs autres entites de traitement nouvelles ou existantes par I'une de I'ensemble des relations de traite- 
ment pour creer un nouveau module de traitement hidrarchique ; et d. le nouveau modele de traitement hi6- 

35 rarchique est memorise dans la zone de m6moire. 

30. Proced6 selon la revendication 29, caracterisS en outre en ce que : 

a. un environnement d'exploitation correspondant a un des composants materiels pr6s6lectionnes est specific 
^0 pour chaque nouvelle construction logique ; 

b. le processeur de donnees a pour fonction d'utiliser les instructions en premier Ian gage de programmation 
dans chaque nouvelle construction logique, celles des entites de traitement, correspondantes p reflect ion nes. 
ceux pr6s6lectionnes des autres modeles de traitement hterarchique, I'ensemble relte d'entites de donnees 
et de relations et les informations d'enttee qui specif lent les donn6es de connexion des composants materiels 

4S reltes a celles des entites de traitement, preselect ion nees correspondantes ; et 

c. le processeur de donnees a pour fonction de distribuer les nouveaux modules de code d'ordinateur aux 
environ nements d'exploitation de ceux des composants materiels preselectionnes, correspondants. 

31. Procede selon la revendication 1 , caracterise en outre en ce que chacune des etapes a a q de la revendication 2 
so sont exScutees dans un des composants du materiel. 

32. Proced§ selon la revendication 30, caracteris6 en outre en ce que chacune des 6tapes a a c sont ex6cutees dans 
un des composants du materiel. 

55 33. Proced6 selon la revendication 1 , caracterisd en outre en ce que la zone de memoire comprend une base de 
donnees relationnelle localisee dans un des composants du materiel pres6lectionnes. 
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